物联网智能柜销售平台（SpringBoot+Netty构建）

这个项目的核心不是做一个“商城网站”，而是把线下的智能售货柜接进一套能实时通信、能下单、能管库存的后端系统。它解决的是一个具体的工程问题：柜子里的设备通过长连接上报状态、接收开柜指令，用户在小程序或 App 上完成购买，服务端要在 SpringBoot 的业务体系里把设备侧的 Netty 通信链路和交易链路串起来。这个导读帮你判断它值不值得拿来对照自己的代码。

技术栈的组合逻辑

SpringBoot 负责的是常规服务端那部分：REST 接口、订单、商品、用户、支付回调、库存扣减。Netty 负责的是另一条链路：柜机设备与服务器的常连接、心跳保活、指令下发、状态上报、异常掉线重连。两者并存，意味着项目里会有一套比较典型的“Web 层 + 通信层”分层结构，而不是把设备通信硬塞进 Controller。

从工程角度看，这套组合的价值在于边界划分。Netty 的 ChannelHandler 里不该出现业务 SQL，交易逻辑也不该关心 TCP 粘包拆包。项目里如果有把这两件事分开处理的设计，就值得抄；如果混得很厉害，也能作为一个反面参照，理解为什么后来要把设备接入层单独拆服务。

可复用程度较高的模块

这类项目里通常有几块是可以直接迁移到其他物联网场景的，不只是售货柜：

• Netty 服务端的启动与配置：端口、线程模型（boss/worker）、编解码器组合、心跳超时处理。
• 自定义协议与消息格式：设备指令和上报数据的结构设计，以及对应的编解码实现。
• 设备会话管理：用 Map 或缓存维护设备编号与 Channel 的映射，支持定向下发指令。
• 指令的异步响应：下发开柜指令后如何等待设备回执、超时如何处理、失败了怎么补偿。
• 库存与订单的一致性处理：下单、支付、开柜、扣库存这几个动作的先后关系和幂等设计。
• SpringBoot 与 Netty 的整合方式：让 Netty 跑在 Spring 容器里，同时能拿到 Service 层的 Bean。

拿这几块去对照，比通读整套目录更有效率。

学习时容易忽略的两个点

协议设计优先于框架使用

很多人看这类项目只会盯着 Netty 的 API 怎么调，但真正决定系统好不好维护的是协议怎么定。一条指令包含哪些字段、用不用消息 ID 做请求响应配对、心跳间隔多久算合理，这些才是设备量上去之后出问题的地方。看代码时先把消息结构理清楚，再看编解码器怎么实现。

业务侧的幂等和时序

支付成功和开柜指令之间是有时间差的，网络抖动、设备离线都会让它们不同步。源码里如果有针对重复通知、指令重发、超时关单的处理，这部分比框架用法更值得花时间。它直接关系到“用户付了钱柜子没开”这类真实故障。

适合拿它做什么

如果你正在做设备接入、共享设备、自助终端一类的后端，这个项目可以作为一个结构参照：看看别人的分层、协议、会话管理是怎么落地的，然后挑能用的部分改造进自己的代码。如果你只是想学 SpringBoot 或 Netty 的入门用法，它可能偏重，因为大量逻辑是围绕具体业务展开的。

建议的路径是：先把设备和服务器之间的通信链路跑通，理解一条指令从发出到回执的完整过程；再回到业务侧，看订单和库存是怎么和通信结果对上的。带着“这条消息如果丢了会怎样”的问题去读，比顺着一遍目录看下来收获更大。