在做 Matter 控制器（controller） 与 Node sidecar（Node 侧车） 通过 IPC（进程间通信） 协作时，很容易把三类现象误当成实现疏漏。把它们想透之后，会发现多半是 产品语义（product semantics）、调用约定（calling convention） 和 实现假设（implementation assumption） 没对齐。本文只谈思路，供同类架构参考。
一、重启后的“重订”：到底在给谁恢复订阅？
很多系统会在 sidecar（侧车） 重启后自动跑一轮 resubscribe（重新订阅），以免状态上报断档。关键问题是：这一轮的集合从哪来？
一种自然想象是：按 fabric（织物网络） 里所有 node（节点） 扫一遍，全网恢复监听。另一种常见实现是：只处理当前仍被上层握在手里的订阅关系——例如以「本进程里仍为某设备注册了回调的设备 ID 集合」为权威列表。
若采用后者，语义非常清晰：没有人在逻辑层订阅（subscribe）的设备，就不在恢复范围内。于是会出现一种“断层感”：写命令（command） 仍可走 RPC（远程过程调用） 直达设备，但收不到上报（report）——因为那条链路上根本没有被登记为“需要持续推送”的订阅方。
这不是“重启没修好”，而是：
- 实现（implementation） 假设：订阅是显式资源，生命周期由 caller（调用方） 管理；
- 产品（product） 若需要“全网常驻监听”，就必须在约定里写清：要么所有关心上报的模块都完成订阅，要么由框架提供单独的“常驻物理订阅”语义，与“带回调的逻辑订阅”区分开。
思路小结：先问清单的 source of truth（可信来源） 是「网络拓扑」还是「本机订阅表」，再谈重启策略；两者不一致时，表现为“能写不能收”，根因在模型不在补丁。
二、悬挂请求：优雅停机与“摔断线”不是同一条路
请求–响应模型里通常有一张 pending（待响应表）：发出 JSON-RPC（JSON 远程调用） 后等待对端回包。
优雅路径（graceful path） 往往做得很好：stop() → shutdown() 时主动 drain（清空） pending，让正在等的调用立刻失败并带上明确原因。这符合用户对“专业停机”的预期。
麻烦在 非受控断开（uncontrolled disconnect）：进程崩溃、管道 EOF、WebSocket（网页套接字） 对端消失等。若此时读侧线程只通知“连接死了”，却不把 pending 里每一档等待改成失败，调用方就只能依赖单条 RPC 的超时（timeout）——而默认超时常常是数十秒量级，体验上就像“卡死”。
析构（Drop） 路径更微妙：资源释放不等于协议层语义完整；若只杀子进程、不通知 pending，同样会拉长空等窗口。
思路小结：
- 把「停机清理」和「连接意外结束」当成两条必须分别设计的路径；
- 在读循环（read loop）结束、能判定 IPC（进程间通信） 已不可恢复时，应同样 fail fast（尽快失败） 所有未完成请求，与优雅 shutdown 对齐体验；
- 若对端假死（连接不断、但不回包），仍要依赖 heartbeat（心跳） 与 per-method timeout（按方法超时），那是第三层问题，不能指望“断线清理”一种机制包打天下。
三、批量接口存在，不等于拥塞自动消失
协议层提供 send_command_batch（批量发命令） 或等价 batch RPC（批量远程调用），侧车内再 并行（parallel） 执行，这是缓解 往返次数（round-trips） 和调度开销的正道。
但若业务层仍习惯“循环里单次 send_command”，那么 IPC 与 sidecar 的压力不会因为库里多了一个批量 API 就下降。API（接口） 存在与**调用模式（calling pattern）**正确是两件事。
思路小结：
- 把“热路径是否批量”纳入 review（评审） 或封装约束，避免在适配层之外散落 N 次单条调用；
- 若改造难度大，可讨论 自适应合并（adaptive batching） 等方案，但要单独评估延迟与**部分失败（partial failure）**语义，属于产品决策，不是顺手优化。
-
结语
这三件事的共同点，是先画清责任边界：谁维护订阅集合、谁在断线时负责让 pending 落地失败、谁保证批量真的被用上。把 约定（convention） 写进架构说明或 on-call（值班） 手册，比事后在日志里猜“是不是又挂了”要省事得多。若你也在做 controller + sidecar 分层，不妨对照自己的 source of truth 和 disconnect（断开） 路径查一遍——往往能有事半功倍的稳定性收益。
