工程上最危险的不是完全不可用，而是在理想环境里正常、进入真实网络和真实数据量后悄悄失去边界。 HTTP 自动 trace 到 WebSocket 后常中断，实时消息需要显式携带 traceparent 或内部等价字段。对端收到后创建 linked span 而非错误继承长期连接 span。
可观测性应回答故障发生在哪个阶段、影响多少会话和是否仍在扩大。事件字段使用白名单与低基数维度，用户内容、密钥和完整网络身份不进入遥测。
工程边界与取舍
落地时要把关键选择变成稳定契约：输入如何校验、状态由谁推进、资源何时释放、旧版本如何降级。只有这样，后续优化才不会改变原有语义。
- 一次用户意图创建 root，信令命令与异步消费创建 child，向 B 的交付使用 link；traceId 随任务短期存在且不作为业务主键。
- 所有输入都设置大小、次数和时间预算，并在超限时返回可操作的稳定错误码。
- 上线参数必须有保守默认值、服务端上限和灰度开关，不能把浏览器传来的数字直接当作资源预算。
“跨信令链路的 Trace Context：把 A、服务端和 B 串成一条因果链”的交付标准是正常路径可用、异常路径收敛、资源有界，并且用户能理解系统为何采用当前状态。 这样得到的不是演示代码，而是能解释、能降级、能回滚的生产能力。
生产环境会怎样出错
不要把异常路径理解成弹一次提示。它还包括在途工作如何停、对端如何获知、残留数据如何处置，以及下一次操作是否会继承旧状态。
- 把整个 WebSocket 生命周期当一个 span 会持续数天且数据巨大；允许客户端指定采样位又可能被攻击者制造昂贵全量追踪。
- 刷新或网络切换同时触发两条恢复路径，重复副作用被误当成两次真实用户操作。
- 只在理想数据量下测试，真实的大文件、长会话或高并发会越过隐含上限并产生级联故障。
把测试跑成闭环
验证需要先写预期状态轨迹，再执行故障注入。每个阶段同时核对用户可见结果、两端协议状态、持久记录和资源计数，才能证明闭环成立。
- 注入一个跨三实例的重复通知故障，验证 trace 能显示两条消费分支、共享 eventId 和各自幂等结果而不含身份内容。
- 让刷新、取消、超时和远端完成在同一调度窗口发生，断言系统只产生一个终态和一次副作用。
- 对日志和埋点做字段白名单检查，证明内容载荷、密钥、完整 IP 与用户可识别信息不会离开设备。
可以上线的标准是：用户知道当前发生了什么，系统在异常后能停止或恢复，资源不会无界增长，运维也能从最小必要证据定位阶段。