仓库架构与边界

当前项目是什么

这个仓库不是单一服务，而是一个围绕 IoT 设备接入和控制的 monorepo。核心目标是打通从设备固件、平台后端、移动端配网到设备控制的完整链路，而不是只提供某一层能力。

当前主链路已经成型：

1. 设备通过 BLE 配网获取 WiFi 与平台地址。
2. 设备向 server/ 激活，获取设备凭证与 MQTT 配置。
3. 设备通过 EMQX / MQTT 接入平台。
4. mobile-app/ 通过 API + MQTT 查看设备并下发控制。

模块边界

server/

平台核心。负责用户、项目、产品、设备、MQTT 鉴权、设备状态同步和 Webhook 数据查询。这里应该保持“基础设施”定位，不要放具体硬件产品的 UI 逻辑或场景规则。

mobile-app/

通用配网与控制客户端。职责是 BLE 配网、账户登录、设备列表与控制，不应承载后端业务规则。与平台交互应尽量通过 iot-libs-common/flutter-sdk/ 完成。

iot-libs-common/flutter-sdk/

Flutter 侧公共 SDK，负责 API/MQTT 能力复用。凡是 App 和后续 Flutter 客户端会重复使用的协议封装、模型和连接逻辑，应优先沉淀在这里，而不是直接写死在页面中。

firmware/

设备侧实现。switch/ 是智能开关，usb-wakeup/ 是 USB HID 唤醒设备。这里应关注设备状态机、联网、激活、MQTT 命令执行和硬件控制，不应混入平台管理逻辑。

smartlink-hub/

偏产品化包装层，主要用于落地页、发布物和面向非开发者的说明。它不是平台内核，不应反向定义 server/ 的架构边界。

当前主要问题

• 仓库叙事还不完全统一，部分文档仍把服务端描述成“独立项目”。
• 后端缺少已提交的 *_test.go，回归保护偏弱。
• Flutter 目录中有遗留页面文件，说明移动端仍有清理空间。

接下来建议

近期优先做三件事：

1. 统一文档口径，明确这是 monorepo，并写清各目录职责。
2. 先补后端基础测试，再继续扩展 API 或设备协议。
3. 清理移动端遗留页面与命名不一致问题，避免后续维护成本扩大。

如果后续进入新功能阶段，建议优先顺序是：补测试基线 -> 固化联调流程 -> 再扩展 Web 管理端或更多硬件支持。