背景：问题从哪来
在 Matter 里，很多属性是挂在 endpoint（端点） 上的，不是挂在「整个节点（node，节点）」上。Bridge（桥）、多路插座、多键开关这类设备，同一个 node id（节点 ID） 下面会有多个端点，各自有自己的 OnOff、计量、传感器等。
上层如果只用「一个设备 ID 对应一份扁平状态」（例如一个 on、一个亮度），那么在工程上很容易出现两类现象：
- 互相覆盖：端点 A 上报开关，端点 B 也上报开关，都写进同一份字段时，后到的报告会把先到的「洗掉」，UI 或自动化看到的是错的端点。
- 语义说不清：回调里只有「一坨状态」，调用方不知道这一坨对应 哪个 endpoint（端点），多端点场景下无法和 Matter 拓扑对齐。
所以问题往往不在「有没有 cache（缓存）」，而在 cache 的粒度 是否和协议一致。
核心思路：两层拆开
把状态拆成两层，概念上很清晰：
- 节点级（node-level）：整条 Matter 节点共有的东西，典型是 在线/离线（online）、连接质量等（按你们 sidecar 实际上报为准）。
- 端点级（endpoint-level）：每个 endpoint id（端点 ID） 各自一份「该端点上的 cluster（簇）属性聚合成的应用状态」。
缓存结构自然就是：节点一块 + 端点 ID → 子状态 的映射。合并（merge）时，必须用事件里带的 endpoint 信息把增量路由到正确的桶里，而不是默认写进全局唯一的那份。
和「增量上报」对齐的合并策略
Matter / sidecar 常见是 增量报告：只带变化字段，没带的不表示「清空」，而是「未报告」。这和「整份覆盖」是两种模型，不能混。
工程上通常约定：
- 每个端点桶内部继续用「仅当本字段有值才覆盖，否则保留旧值」的合并语义；
- 在线状态更适合放在节点级，并且可以和「任意一条带 online 的事件」同步（具体以你们事件为准）。
对于 事件里没有 endpoint（端点） 的旧数据或兼容路径，要在设计里写死一条默认策略（例如落到默认端点 1），并在文档里说明，避免不同模块各自猜测。
对上层的 API（接口）怎么暴露：快照和增量可以并存
只改内部结构不够，还要让调用方用得对、不歧义。常见两种需求：
- 拉全量：例如 UI 冷启动、对账、调试——需要「当前整棵树长什么样」。适合
fetch_state一类返回完整快照（节点 + 各端点）。 - 推更新：和设备的推送节奏一致——适合 增量回调，每次通知里带上 本条事件对应的 endpoint（端点） 以及 该端点在合并后的完整子快照（让调用方不必自己再实现一遍 merge（合并）规则）。
注意：增量回调里更稳妥的是给 「该端点当前完整子状态」，而不是只给原始 patch（补丁）——除非你们明确承诺 patch 语义并让上层负责合并，否则容易踩坑。
若业务需要「每次推送都是整张图」，可以单独提供 快照订阅（每次事件后推完整 DeviceSnapshot），和增量订阅并存；过滤订阅（filter） 只决定「何时调用回调」，不必再发明第三种回调形状。
订阅与物理链路：Rust 与 sidecar 的分工
很多系统里 sidecar（侧车）是无状态或易失的：进程重启后内存里的订阅表没了。这时 Rust 侧（Rust 侧） 必须在恢复连接后，对「仍需要推送的设备」做一轮 重订（resubscribe）；否则网关还能 写命令，但 读上报 会断。这和「按端点分桶」是正交能力，但要一起在架构文里写清楚，否则线上表现为「重启后偶发瞎了半套」。
迁移与兼容：怎么少折腾老调用方
- 读路径：若旧契约只认「单端点灯具」那种模型，可以保留一个 「主端点视图」（例如端点 1 + 节点 online 拼成过去那一坨
DeviceState的语义），专门给 CLI、mhome、老 UI 用，避免一次性推翻所有集成。 - 写路径：控制命令本来就可以带
endpoint_id，与分桶模型一致。 - 订阅路径：回调从「一坨状态」变成「带端点信息的更新」，是 破坏性变更，需要在发版说明里写清楚；文档示例要同步，否则别人抄 README 会抄错。
小结
- 根因：扁平 per-device 状态与 Matter 的 per-endpoint 现实不一致，导致覆盖与语义歧义。
- 做法：节点级状态 + 按 endpoint 分桶，事件合并时 按路径路由；拉用快照、推用增量（可叠加快照订阅）。
- 落地关键：默认无 endpoint 的策略、online 放哪一层、以及和 sidecar 重启 / 重订 一起纳入运维与测试场景。
