结合 Taichi2.0 的真实代码和设计文档，完整拆解通信指令计划、MQTT 响应关联、Command 工厂、属性单位规则匹配、Caffeine 缓存与 InfluxDB 数据组装，并给出可实施的可靠性重构、代码架构、测试和上线路线。

本文基于 D:\WorkSpace\Electric\cloud-web\03.Code\Taichi 项目，整理一次从零增加预警告警能力的完整过程。这个模块的核心目标是：设备上报 PropertiesReport 后，系统可以按规则判断某个属性值是否异常，命中规则后发送 Email 通知，并可选地向设备下发一条自动指令，同时沉淀告警记录用于追溯。

一、业务目标

预警告警模块要解决四件事：

1. 管理 Email 联系人和邮箱地址。
2. 配置预警规则：选择 PropertiesReport 字段、比较条件、阈值、监控设备或分组、通知联系人。
3. 命中预警后自动处理：发送邮件，或者额外选择通信协议并下发自定义 Payload。
4. 保存告警记录：记录触发规则、触发设备、实际值、原始 PropertiesReport Payload、邮件发送结果和自动指令发送结果。

这篇记录 D:\WorkSpace\Electric\cloud-web\03.Code\Taichi 里 MQTT 模块的拆分过程。目标不是改业务，而是把 MQTT 的基础设施能力单独抽出来，保留现有设备、通信、固件和系统权限逻辑。

一、旧模块的问题

旧实现把 MQTT 基础能力和业务处理放在同一个 com.yinyang.yin.mqtt 包下，结果是：

1. 连接管理、订阅、发布、分发、DTO 和业务 Handler 混杂。
2. MQTT 基础层直接感知设备、固件、告警、Influx 等业务服务。
3. 业务改动会反向污染 MQTT 基础代码，单独复用也困难。
4. 后续如果想把 MQTT 给别的项目用，几乎只能整包复制。