设备影子怎么用：期望状态与上报状态的分离

设备影子是平台侧保存的一份设备状态副本，分成两部分：期望状态是业务希望设备处于的样子，上报状态是设备实际报上来的样子。两者一致说明同步完成，不一致说明有一次变更还在路上。

它解决的核心问题是离线

没有影子机制时，给离线设备下发配置只有两个选择：直接失败让用户重试，或者在业务代码里自己实现一个待下发队列。前者体验差，后者是在每个业务里重复造同一个轮子。

有了影子，业务只需要写期望状态，平台负责在设备上线时推送差异。设备上报新状态后，平台比对两份状态，一致则认为完成。业务侧不必关心设备当前是否在线。

适合管什么

• 配置类：上报间隔、阈值、工作模式。这类值变更不频繁、需要持久化、且设备重启后应当保持；
• 期望的工作状态：目标温度、开关状态。注意这里管的是「期望」，实际是否达到由上报状态反映。

不适合管什么

一次性动作不适合。「重启设备」「执行一次校准」这类指令没有状态的概念 —— 写进期望状态之后，设备每次上线都会看到这个期望值与上报值不一致，于是反复执行。这类指令应当走服务调用，带超时和明确的执行结果。

高频遥测也不适合。影子的每次更新都要持久化并可能触发通知，用它承载秒级的温度上报，会把存储和通知量放大到不必要的程度。遥测走数据通道，影子只管状态。两者的边界建议在物联网平台解决方案的接口文档里写明。

冲突怎么处理

设备在离线期间被现场人工操作改了状态，上线后上报的值与平台的期望值不一致。这时该听谁的，是业务决策而非技术决策，但必须明确定义，常见的三种约定是：

1. 平台优先：重新下发期望值，覆盖现场操作。适合集中管控的场景；
2. 设备优先：以上报值更新期望值，承认现场操作。适合允许本地干预的场景；
3. 标记冲突：两者都保留，交由人工确认。适合变更影响较大的场景。

无论选哪种，都应当记录冲突发生的事实。静默地按某一方覆盖，会让现场人员觉得「我明明调过了，它自己又变回去」，而且查不出原因。

版本号不能省

影子更新要带版本号，设备上报时带上它看到的版本。版本不匹配说明期间又有过变更，设备应当重新拉取。没有版本号的实现，在并发更新时会出现后发的请求被先到的覆盖。这类并发语义在平台与系统开发中属于必须在接口设计阶段确定的部分。