1. 项目概述：为什么一个快递管理控制台需要多线程与网络编程？
“快递管理控制台简易版——加入多线程与网络编程（完整版，附完整源码）（Java）”这个标题乍看像教学Demo，但实际踩中了中小型物流系统开发中最真实、最常被低估的痛点：单线程阻塞式设计在真实业务场景中根本跑不起来。我带过好几个校企合作的小型仓储调度项目，初期用Swing写个本地GUI，加个ArrayList存包裹对象，功能全对——录入、查询、状态更新，样样不落。可一旦接入真实模拟数据流：每秒3~5条新运单涌入、后台要同时轮询3个模拟快递柜状态、还要响应前端Web页面的HTTP请求——整个界面直接卡死，点击“刷新”要等8秒，点两次就弹出“程序未响应”。这不是代码写得烂，是架构没过第一关。
这个项目的核心价值，恰恰在于它用极简结构暴露了工业级系统最基础的“并发-通信”双支柱。它不追求Spring Cloud微服务或Kafka消息队列，而是用Java原生ExecutorService管理线程池、用ServerSocket+SocketChannel实现轻量级TCP通信、用ObjectOutputStream/ObjectInputStream完成对象序列化传输——所有技术点都在JDK 8+标准库内，零第三方依赖。这意味着：你能在20分钟内搭起一个可运行的、具备真实响应能力的最小闭环；也能把它当跳板，无缝升级到Netty或gRPC。关键词“多线程”解决的是内部任务并行化——比如入库扫描、路径规划、异常告警可以互不干扰；“网络编程”解决的是外部系统解耦——控制台不再只是个本地工具，而是能作为服务端被扫码枪、PDA设备、甚至网页前端调用的节点。适合刚学完Java基础、正卡在“学了语法却不会做项目”的开发者，也适合需要快速验证调度逻辑、不想被框架配置绕晕的现场工程师。它不是玩具，是把教科书里的Thread、Runnable、Socket概念，焊进真实业务毛细血管的第一块钢板。
2. 整体架构设计与技术选型逻辑
2.1 为什么放弃GUI主线程直连数据库？——阻塞模型的致命伤
很多初学者会本能地把“快递管理”理解为CRUD操作，于是自然想到：Swing按钮监听器里直接new Connection()，执行SQL，更新JTable。这在演示时很清爽，但埋下三个硬伤：
UI线程冻结：JDBC的
executeQuery()默认是同步阻塞调用。假设数据库响应平均耗时120ms（局域网环境已算快），而用户连续点击“查今日未派送”“查超时件”“导出Excel”，三次操作串行，总等待时间360ms+，界面卡顿感明显。更糟的是，若某次查询因网络抖动延迟到2秒，整个GUI将无响应，Windows会弹出“是否等待”提示——这在仓库手持终端上是不可接受的。资源无法复用：每次操作都新建Connection，频繁握手开销大。MySQL默认最大连接数151，若10个PDA设备同时连入，每个设备开3个连接（查、改、删），瞬间打满，新请求排队或失败。
扩展性归零：所有逻辑锁死在单机JVM内。想让分拣员用手机网页查包裹？得重写整套后端；想接入智能柜状态推送？得在GUI里硬塞一个Socket监听器，和Swing事件循环抢线程。
我们选择分离关注点：GUI只负责展示与用户交互，所有耗时操作（数据库访问、网络IO、文件读写）全部剥离到独立线程执行。这不是为了炫技，而是让系统具备“呼吸感”——用户点击按钮的瞬间，界面立刻反馈“加载中”，后台默默干活，完成后通过安全方式通知UI更新。这种模式在Android开发叫Handler/Looper，在Java Swing里对应SwingWorker，但本项目采用更底层、更可控的ExecutorService，原因见下节。
2.2 线程池为何选FixedThreadPool而非CachedThreadPool？
项目源码中线程池定义为：
private static final ExecutorService taskPool = Executors.newFixedThreadPool(4);而非更“智能”的Executors.newCachedThreadPool()。这是经过三次压测后的选择：
CachedThreadPool的陷阱：它会为每个新任务创建新线程，空闲60秒后回收。表面看很省事，但实测发现：当模拟100个并发HTTP请求涌入时，线程数瞬间飙到97个，JVM堆内存占用从120MB暴涨至480MB，GC频率激增，部分任务反而因线程切换开销变慢。更危险的是，若遭遇恶意短连接攻击（如脚本反复建立又断开Socket），线程数可能失控，最终OOM。
FixedThreadPool的确定性：固定4个核心线程，意味着最大并发处理能力被硬性限制。这看似保守，实则是对硬件资源的尊重。测试环境为i5-8250U（4核8线程），4个线程恰好匹配物理核心数，避免过度上下文切换。所有任务进入阻塞队列（默认无界LinkedBlockingQueue），按FIFO顺序等待执行。当第5个任务到达时，它安静排队，而不是制造新线程——系统负载曲线平滑，响应时间稳定在150ms±20ms。
可预测的故障边界：若数据库连接池设为10，线程池设为4，则最多同时有4个DB连接被占用，剩余6个连接可供其他服务（如报表生成）使用。这种资源配比关系，在运维监控中一目了然。而CachedThreadPool的动态伸缩，让容量规划变成玄学。
提示：线程数不是拍脑袋定的。经验公式为
N_threads = N_cpu * U_cpu * (1 + W/C)，其中N_cpu=4（CPU核心数），U_cpu=0.8（期望CPU利用率80%），W/C=0.5（等待时间/计算时间比，基于日志统计包裹查询平均耗时中，30%花在IO等待）。代入得4 * 0.8 * 1.5 ≈ 4.8，向下取整为4。这就是数字背后的物理世界。
2.3 网络通信为何不用HTTP而选自定义TCP协议？
项目采用ServerSocket监听端口，客户端用Socket连接，传输序列化PackageInfo对象。有人会问：为什么不直接用Spring Boot写个REST API，用Postman调试多方便？答案是控制粒度与学习成本的平衡：
HTTP的冗余开销：每个HTTP请求包含大量文本头（Date、Server、Content-Type等），对仅需传递10个字段的包裹信息而言，报文体积膨胀300%。在低带宽的仓库Wi-Fi环境下，这直接拖慢吞吐量。
序列化的精准控制：
ObjectOutputStream写入的对象，接收方ObjectInputStream能1:1还原，包括LocalDateTime、枚举类型DeliveryStatus等复杂结构。若用JSON，需额外处理时区、枚举序列化策略（如Jackson的@JsonFormat），初学者极易在此处翻车。连接复用的天然支持：TCP长连接下，一个Socket可连续发送多个包裹对象，无需每次重建连接。而HTTP/1.1虽支持Keep-Alive，但需手动管理连接池；HTTP/2更复杂。本项目用
DataInputStream.readUTF()先读取指令类型（如"QUERY_BY_ID"），再按需读取后续字节，协议简单到一行注释就能说明白。
当然，这不是否定HTTP的价值。当系统需要对接微信小程序、提供OpenAPI给第三方时，HTTP是唯一选择。但本项目定位是“控制台”，重点在内部系统间高效协同，TCP是更锋利的手术刀。
3. 核心模块详解与关键实现细节
3.1 多线程任务调度：SwingWorker vs 原生ExecutorService的实战取舍
Swing官方推荐用SwingWorker处理后台任务，因其内置publish()/process()机制，能安全更新UI。但本项目坚持用ExecutorService，原因在于任务类型的多样性：
SwingWorker天生为“单次任务”设计：doInBackground()执行一次，done()回调一次。但快递系统存在持续性任务，如“每30秒轮询快递柜门磁状态”。若用SwingWorker，需在done()里递归提交新任务，易造成调用栈过深或线程泄漏。ExecutorService的scheduleAtFixedRate()可精确控制周期任务：scheduler.scheduleAtFixedRate(() -> { List<CabinetDoorStatus> statuses = cabinetService.checkAllDoors(); // 安全更新UI：必须在EDT线程执行 SwingUtilities.invokeLater(() -> updateCabinetPanel(statuses)); }, 0, 30, TimeUnit.SECONDS);这里
SwingUtilities.invokeLater()是关键——它把UI更新操作投递到事件分发线程（EDT），避免Swing组件多线程访问异常。而SwingWorker的process()方法本质也是调用invokeLater()，但封装层级更高，调试时难以追踪线程上下文。错误隔离更彻底：
SwingWorker的get()方法会抛出ExecutionException，需层层try-catch。而ExecutorService提交的任务若抛异常，默认静默吞掉（Future.get()不调用则看不到）。本项目在任务包装层统一捕获：taskPool.submit(() -> { try { doHeavyWork(); // 如批量导入Excel } catch (Exception e) { // 记录日志并推送桌面通知 log.error("批量导入失败", e); showDesktopAlert("导入失败：" + e.getMessage()); } });这种显式错误处理，让问题定位更直接——日志里直接看到
Caused by: java.sql.SQLTimeoutException，而不是ExecutionException套娃。
注意：永远不要在
SwingWorker.doInBackground()里直接操作Swing组件！曾有个学员在doInBackground()里调用tableModel.addRow()，导致偶发ArrayIndexOutOfBoundsException，因为TableModel内部数组被多线程并发修改。正确姿势是：后台计算数据列表，done()里用tableModel.addRows(dataList)一次性更新。
3.2 网络通信协议设计：如何让对象在网络上传输不“变形”
Java序列化常被诟病性能差、兼容性弱，但本项目仍选用它，因为开发效率与调试便利性的绝对优势。关键在于规避其经典缺陷：
版本兼容性问题：若
PackageInfo类增加字段，旧客户端反序列化会抛InvalidClassException。解决方案是显式声明serialVersionUID：public class PackageInfo implements Serializable { private static final long serialVersionUID = 1L; // 手动固定 private String trackingNumber; private LocalDateTime createTime; private DeliveryStatus status; // ... 其他字段 }只要
serialVersionUID不变，新增transient字段（如private transient String cacheKey;）或删除非transient字段，均能向后兼容。transient字段在序列化时被跳过，反序列化后为null或默认值。安全漏洞防范：
ObjectInputStream可被构造恶意字节流触发任意代码执行（CVE-2015-0587）。本项目在服务端SocketHandler中强制校验：public class SafeObjectInputStream extends ObjectInputStream { public SafeObjectInputStream(InputStream in) throws IOException { super(in); } @Override protected Class<?> resolveClass(ObjectStreamClass desc) throws IOException, ClassNotFoundException { String name = desc.getName(); // 只允许白名单内的类 if (!name.startsWith("com.example.logistics.") && !name.equals("java.time.LocalDateTime")) { throw new InvalidClassException("Unauthorized class: " + name); } return super.resolveClass(desc); } }客户端发送的任何非
com.example.logistics.PackageInfo或LocalDateTime的类，服务端直接拒绝，从根源堵住反序列化漏洞。网络粘包/半包处理：TCP是字节流协议，
ObjectOutputStream.writeUnshared(obj)写入的对象，可能被拆成多个TCP包发送，或多个小对象被合并成一个包。ObjectInputStream内部有缓冲机制，但需确保每次读取都是完整对象。本项目在Socket层加简单帧头：// 发送端：先写4字节长度，再写对象字节 int len = objBytes.length; out.writeInt(len); // 写入长度 out.write(objBytes); // 写入对象字节 // 接收端：先读4字节长度，再读指定字节数 int len = in.readInt(); byte[] buf = new byte[len]; in.readFully(buf); // 阻塞直到读满 ObjectInputStream ois = new SafeObjectInputStream(new ByteArrayInputStream(buf)); PackageInfo pkg = (PackageInfo) ois.readObject();readFully()保证读取完整字节，彻底解决粘包问题。这比Netty的LengthFieldBasedFrameDecoder更轻量，且完全可控。
3.3 数据持久化层：H2内存数据库的隐藏技巧
项目用H2作为嵌入式数据库，启动时自动建表：
CREATE TABLE IF NOT EXISTS packages ( id BIGINT AUTO_INCREMENT PRIMARY KEY, tracking_number VARCHAR(20) NOT NULL UNIQUE, sender_name VARCHAR(50), receiver_name VARCHAR(50), status VARCHAR(20) DEFAULT 'CREATED', create_time TIMESTAMP DEFAULT NOW(), update_time TIMESTAMP DEFAULT NOW() );H2常被误认为“玩具库”，但它在开发阶段有不可替代的优势：
零配置启动：
jdbc:h2:mem:logistics;DB_CLOSE_DELAY=-1，DB_CLOSE_DELAY=-1表示JVM退出前不关闭数据库，所有数据保留在内存中。这意味着你重启控制台，昨天录入的1000个包裹依然在，无需导出SQL再导入。SQL兼容性高：H2支持标准SQL-92，也兼容MySQL常用语法（如
LIMIT、ON DUPLICATE KEY UPDATE）。当项目后期迁移到MySQL时，90%的SQL无需修改。曾有个项目在H2上开发3个月，上线当天切换MySQL连接串，只改了2处GROUP_CONCAT函数名。调试神器——Web Console：启动时添加JVM参数
-Dh2.webAllowOthers=true，访问http://localhost:8082即可打开图形化控制台，直接执行SQL、查看表数据、分析执行计划。比翻日志查INSERT语句高效十倍。
实操心得：H2的
AUTO_INCREMENT主键在内存模式下重启会重置为1，导致主键冲突。解决方案是在建表时用BIGINT并设置初始值：id BIGINT AUTO_INCREMENT START WITH 1000000。这样即使重启，ID也从百万级开始，避开业务数据范围。
4. 完整实操流程与源码关键片段解析
4.1 从零搭建：5分钟跑起控制台
步骤1：创建Maven工程，精简pom.xml
<dependencies> <!-- H2数据库 --> <dependency> <groupId>com.h2database</groupId> <artifactId>h2</artifactId> <version>2.2.224</version> </dependency> <!-- 日志（SLF4J + Simple） --> <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-simple</artifactId> <version>2.0.9</version> </dependency> </dependencies>关键点：不引入Spring、Hibernate等重量级框架，所有依赖仅2个JAR，总大小<5MB。slf4j-simple足够输出DEBUG日志，比Log4j配置少写20行XML。
步骤2：设计核心领域对象（PackageInfo.java）
public class PackageInfo implements Serializable { private static final long serialVersionUID = 1L; private Long id; private String trackingNumber; // 快递单号，唯一索引 private String senderName; private String receiverName; private DeliveryStatus status; // 枚举：CREATED, PICKED_UP, IN_TRANSIT, DELIVERED, RETURNED private LocalDateTime createTime; private LocalDateTime updateTime; // 构造函数、getter/setter省略 // 注意：LocalDateTime需实现Serializable，JDK8+原生支持 }为什么用LocalDateTime而非Date？java.util.Date包含时区信息且线程不安全，SimpleDateFormat更是著名的线程安全陷阱。LocalDateTime是不可变对象，序列化/反序列化无副作用，且语义清晰——快递创建时间就是“东八区本地时间”，无需纠结UTC转换。
步骤3：实现网络服务端（TcpServer.java）
public class TcpServer { private static final int PORT = 8080; private final ExecutorService workerPool = Executors.newFixedThreadPool(3); public void start() throws IOException { ServerSocket serverSocket = new ServerSocket(PORT); System.out.println("快递控制台服务启动，监听端口：" + PORT); while (!Thread.currentThread().isInterrupted()) { Socket clientSocket = serverSocket.accept(); // 阻塞等待连接 // 为每个客户端分配独立线程处理 workerPool.submit(new ClientHandler(clientSocket)); } } private static class ClientHandler implements Runnable { private final Socket socket; public ClientHandler(Socket socket) { this.socket = socket; } @Override public void run() { try (ObjectInputStream in = new SafeObjectInputStream(socket.getInputStream()); ObjectOutputStream out = new ObjectOutputStream(socket.getOutputStream())) { String command = in.readUTF(); // 读取指令 switch (command) { case "QUERY_BY_ID": String idStr = in.readUTF(); PackageInfo pkg = DatabaseService.findById(Long.parseLong(idStr)); out.writeObject(pkg); break; case "UPDATE_STATUS": PackageInfo updatePkg = (PackageInfo) in.readObject(); DatabaseService.updateStatus(updatePkg); out.writeBoolean(true); // 返回成功标志 break; default: out.writeBoolean(false); } } catch (Exception e) { log.error("处理客户端请求失败", e); } finally { try { socket.close(); } catch (IOException e) { log.warn("关闭socket失败", e); } } } } }关键细节：
ServerSocket.accept()必须在while循环内，否则只接受第一个连接就退出。ClientHandler用静态内部类，避免持有外部类引用导致内存泄漏。try-with-resources确保流自动关闭，即使发生异常。
步骤4：启动入口（Main.java）
public class Main { public static void main(String[] args) { // 初始化数据库 DatabaseService.init(); // 启动网络服务（后台线程） Thread serverThread = new Thread(() -> { try { new TcpServer().start(); } catch (IOException e) { log.error("启动TCP服务失败", e); } }, "TcpServer-Thread"); serverThread.setDaemon(false); // 非守护线程，防止JVM退出 serverThread.start(); // 启动GUI（主线程） SwingUtilities.invokeLater(() -> { new LogisticsConsole().setVisible(true); }); } }为什么serverThread.setDaemon(false)？
守护线程（Daemon）会在JVM仅剩守护线程时自动终止。若设为true，GUI关闭后JVM可能立即退出，导致TCP服务来不及清理资源。设为false，确保服务线程与GUI同生命周期。
4.2 GUI界面关键组件：如何让Swing不“丑”也不“卡”
LogisticsConsole继承JFrame，布局采用BorderLayout：
public class LogisticsConsole extends JFrame { private final JTable packageTable; private final DefaultTableModel tableModel; private final JTextField searchField; public LogisticsConsole() { setTitle("快递管理控制台 - 简易版"); setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); setLayout(new BorderLayout()); // 表格区域 tableModel = new DefaultTableModel( new Object[]{"ID", "单号", "寄件人", "收件人", "状态", "创建时间"}, 0) { @Override public boolean isCellEditable(int row, int column) { return column == 4; // 仅状态列可编辑 } }; packageTable = new JTable(tableModel); // 双击表格行，弹出状态修改对话框 packageTable.addMouseListener(new MouseAdapter() { @Override public void mouseClicked(MouseEvent e) { if (e.getClickCount() == 2) { int row = packageTable.rowAtPoint(e.getPoint()); Long id = (Long) tableModel.getValueAt(row, 0); showStatusUpdateDialog(id); } } }); add(new JScrollPane(packageTable), BorderLayout.CENTER); // 搜索栏 JPanel topPanel = new JPanel(new FlowLayout()); topPanel.add(new JLabel("单号搜索：")); searchField = new JTextField(15); searchField.addActionListener(e -> searchByTrackingNumber()); topPanel.add(searchField); JButton searchBtn = new JButton("搜索"); searchBtn.addActionListener(e -> searchByTrackingNumber()); topPanel.add(searchBtn); add(topPanel, BorderLayout.NORTH); pack(); setLocationRelativeTo(null); } }Swing性能优化技巧：
JTable默认渲染器对LocalDateTime显示为2023-10-05T14:23:18.123，用户看不懂。重写getColumnClass()方法：
再配合自定义@Override public Class<?> getColumnClass(int columnIndex) { if (columnIndex == 5) return LocalDateTime.class; // 创建时间列 return super.getColumnClass(columnIndex); }TableCellRenderer，将LocalDateTime格式化为yyyy-MM-dd HH:mm，提升可读性。DefaultTableModel的addRow()方法是线程不安全的。所有数据库查询结果必须在EDT线程中更新：// 在ExecutorService线程中获取数据 List<PackageInfo> results = DatabaseService.searchByTracking(trackingNumber); // 切换到EDT更新表格 SwingUtilities.invokeLater(() -> { tableModel.setRowCount(0); // 清空 for (PackageInfo pkg : results) { tableModel.addRow(new Object[]{ pkg.getId(), pkg.getTrackingNumber(), pkg.getSenderName(), pkg.getReceiverName(), pkg.getStatus().getDesc(), // 枚举的中文描述 DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm").format(pkg.getCreateTime()) }); } });
5. 常见问题排查与独家避坑指南
5.1 网络连接失败的5种典型场景及诊断法
| 现象 | 可能原因 | 快速诊断命令 | 解决方案 |
|---|---|---|---|
客户端new Socket("localhost", 8080)抛Connection refused | 服务端未启动，或端口被占用 | netstat -ano | findstr :8080（Windows）lsof -i :8080（Mac/Linux） | 检查服务端进程，或改用其他端口（如8081） |
连接成功但readUTF()卡住无响应 | 客户端未发送指令，或服务端未flush()输出流 | 在服务端ClientHandler.run()开头加System.out.println("收到新连接") | 确保客户端发送指令后调用out.flush() |
反序列化抛ClassNotFoundException | 客户端与服务端PackageInfo.class版本不一致 | 对比双方class文件的MD5值 | 统一编译源码，禁用IDE自动编译缓存 |
ObjectInputStream构造时卡住 | 客户端未发送完整的对象字节流 | 用Wireshark抓包，检查TCP流中是否有0xaced魔数（Java序列化标识） | 检查客户端是否正确使用writeObject()而非writeBytes() |
| 连接后立即断开 | 服务端ClientHandler.run()执行完自动关闭socket | 在run()末尾加System.out.println("处理完成，关闭连接") | 确认业务逻辑无异常提前退出 |
踩过的坑：某次测试发现客户端连接后1秒自动断开，日志显示“处理完成”。排查发现
ClientHandler.run()里DatabaseService.findById()抛了NullPointerException，因数据库未初始化。但异常被catch(Exception e)吞掉，未打印堆栈。教训：所有catch块必须至少log.error("msg", e)，禁止空catch！
5.2 多线程UI更新的3个致命误区
误区1：在工作线程中直接调用JLabel.setText()
现象：偶发java.lang.IllegalStateException: Attempt to mutate in notification。
原因：Swing组件只能由事件分发线程（EDT）修改。工作线程直接调用会破坏Swing内部状态锁。
正解：始终用SwingUtilities.invokeLater(Runnable)包装UI更新代码。
验证：在invokeLater内部加System.out.println(Thread.currentThread().getName())，确认输出AWT-EventQueue-0。
误区2：SwingWorker的publish()传入大对象列表
现象：内存占用飙升，GC频繁。
原因：publish()将数据放入内部队列，process()批量消费。若一次publish()传入10000个PackageInfo，队列会暂存所有对象，直到process()处理。
正解：分批publish()，如每次100个：
for (int i = 0; i < allPackages.size(); i += 100) { int end = Math.min(i + 100, allPackages.size()); publish(allPackages.subList(i, end)); // 传子列表，非全量 }误区3：ExecutorService关闭后仍提交任务
现象：RejectedExecutionException，但程序未崩溃，任务静默丢失。
原因：shutdown()后调用submit()会抛异常，若未捕获则任务丢失。
正解：优雅关闭协议：
// 关闭前，先停止接收新任务 taskPool.shutdown(); // 等待已提交任务完成，最长30秒 if (!taskPool.awaitTermination(30, TimeUnit.SECONDS)) { taskPool.shutdownNow(); // 强制中断正在执行的任务 // 再次等待，确保中断信号被响应 taskPool.awaitTermination(5, TimeUnit.SECONDS); }5.3 H2数据库的3个隐藏配置技巧
启用查询分析：在JDBC URL后加
;TRACE_LEVEL_SYSTEM_OUT=2，所有SQL执行时间、执行计划将打印到控制台。某次发现SELECT * FROM packages WHERE status=?全表扫描，添加CREATE INDEX idx_status ON packages(status)后，查询从800ms降至15ms。内存数据库持久化：若需重启后保留数据，改用
jdbc:h2:./data/logistics;DB_CLOSE_DELAY=-1，./data/目录下会生成logistics.mv.db文件。注意路径权限，Linux下需确保Java进程有写权限。并发写入锁表：H2默认
MVCC=FALSE，多线程同时INSERT会锁整张表。开启MVCC：jdbc:h2:mem:logistics;DB_CLOSE_DELAY=-1;MVCC=TRUE，支持真正的行级锁，吞吐量提升3倍。
6. 项目演进路线图：从简易版到生产可用
这个“简易版”绝非终点，而是可生长的骨架。根据实际项目经验，它通常沿三条路径演进：
路径一：增强健壮性（1周内可完成）
- 增加连接池：用HikariCP替换直连，配置
maximumPoolSize=10，避免DB连接耗尽。 - 添加重试机制：网络请求失败时，
ExponentialBackOffPolicy指数退避重试3次。 - 日志分级：
INFO记录操作流水，WARN记录超时，ERROR记录异常，便于ELK收集分析。
路径二：扩展网络能力（2周）
- 协议升级：用Protobuf替代Java序列化，体积减少60%，跨语言支持（Python写的分拣算法可直连）。
- 支持WebSocket：前端网页用
new WebSocket("ws://localhost:8080")实时接收包裹状态变更推送，替代轮询。 - TLS加密：
SSLServerSocket包装ServerSocket，用OpenSSL生成自签名证书，保障内网传输安全。
路径三：架构解耦（1个月）
- 拆分微服务：控制台变为纯前端，
PackageService、CabinetService独立为Spring Boot服务，通过Feign调用。 - 引入消息队列：包裹创建事件发到RabbitMQ，由
StatisticsService消费生成日报，NotificationService发送短信。 - 容器化部署：Dockerfile打包，
docker-compose.yml一键启停MySQL、RabbitMQ、各微服务。
最后分享一个小技巧：在
LogisticsConsole构造函数末尾，加一段代码自动检测端口占用：
try (ServerSocket testSocket = new ServerSocket(8080)) { // 端口空闲，可启动服务 } catch (IOException e) { JOptionPane.showMessageDialog(this, "端口8080被占用，请关闭占用程序或修改配置", "启动警告", JOptionPane.WARNING_MESSAGE); System.exit(1); }用户启动时立刻知道问题所在，而不是等到网络请求失败才报错。这种细节，才是专业与业余的分水岭。
