ThinkLink 属性有值却没有 MQTT 消息：检查白名单与数据归属

先决定字段应该存在哪里

采集结果通常放遥测，平台维护的业务参数放服务端属性，共享配置按相应属性定义使用，计算中间状态放 process_data。当前应用参数另有 app_attrs 归属，不能把所有内容都塞进一个频繁转发的大对象。每个字段应注明作者、读取者、是否需要历史曲线和外部消费者。这是数据设计问题，而不只是改一个开关。过程数据虽然用于中间计算，但并非自动过期的临时内存；存量脚本迁移时要核对初始状态，避免把新位置的空值当成累计量从零开始。

白名单控制哪些属性进入消息

当前文档规定服务端和共享属性默认不转发，只发送保存后的 forward_fields 白名单中实际存在的顶层字段。缺配置、空组与空数组都不能推导为全量转发。勾选字段不会删除其他属性，也不表示立即发出一次消息；需要后续实际的数据更新或相应转发动作。嵌套对象按顶层键选择，不能用一个看似路径的字符串假定只公开其中一个子字段。涉及较大的配置对象时，先检查外部到底需要哪些信息，再决定字段结构与转发范围。

保存规则和脚本补丁不是同一结构

设备与模板保存的是字段名数组，脚本返回的 forward_fields 则使用布尔补丁语义，增加或移除指定字段，省略部分保持不变。不要把两种结构混用。RPC 中 forward 为 true 也不绕过属性白名单；为 false 的具体作用按对应动作文档理解，不能扩大为禁止所有协议同步。过程数据通过模型结果或 RPC 动作写入，直接修改只读输入并不会保存。内置转发排除过程数据，但自行构造的自定义 MQTT 消息仍由脚本作者决定内容，不能把排除规则当作所有出口的保证。

让消费端验证局部更新

在测试对象上设置两个普通属性，只选择一个转发，触发适当更新后分别查看设备现值和目标 Broker 消息。确认未选字段仍保存在平台但没有出现在该消息中，再关闭选中字段验证预期行为。接收端必须按字段合并消息中的子集，不能用局部消息覆盖整组属性，否则未发送的值会被误删。规则变更、消息生成、Broker 转发和消费端处理是不同步骤，应分别记录证据。仅看到连接为 RUNNING 或保存按钮成功，都不能替代收到正确字段的检查。

1. 确认字段类型与实际消费者。
2. 保存最小必要的转发白名单。
3. 触发测试更新并检查目标消息。
4. 验证消费端合并与模板重置影响。

把模板和版本变化纳入交接

模板可携带转发规则，重置设备时会用模板覆盖；旧模板没有规则可能使属性恢复默认不转发。批量变更前应比较模板与设备规则，列出受影响的外部消费者。过程数据的正常落盘可跨重启恢复，但缓冲写入尚未完成时不能把缓存读取成功当成持久化证明。交付应提供字段归属表、白名单、消费者合并方式和样本消息，并注明对应版本。若只是要把共享配置送到实际设备，还需要适用的 RPC 下行；修改属性或向外部 MQTT 转发都不等于无线设备已收到参数。