工程上最危险的不是完全不可用，而是在理想环境里正常、进入真实网络和真实数据量后悄悄失去边界。 时间序列数量近似各标签取值的笛卡尔积。即使请求量不大，一个 unbounded errorMessage 或 peerId 也会每天创建数百万序列。
可观测性应回答故障发生在哪个阶段、影响多少会话和是否仍在扩大。事件字段使用白名单与低基数维度，用户内容、密钥和完整网络身份不进入遥测。
工程边界与取舍
落地时要把关键选择变成稳定契约：输入如何校验、状态由谁推进、资源何时释放、旧版本如何降级。只有这样，后续优化才不会改变原有语义。
- 指标 schema 列出允许标签和预计基数，错误映射到稳定 code，路径使用模板；后端设置每指标 active-series 限额并丢弃未知标签。
- 所有输入都设置大小、次数和时间预算，并在超限时返回可操作的稳定错误码。
- 上线参数必须有保守默认值、服务端上限和灰度开关，不能把浏览器传来的数字直接当作资源预算。
“指标基数预算：一个 userId 标签足以拖垮监控系统”的交付标准是正常路径可用、异常路径收敛、资源有界，并且用户能理解系统为何采用当前状态。 这样得到的不是演示代码，而是能解释、能降级、能回滚的生产能力。
生产环境会怎样出错
不要把异常路径理解成弹一次提示。它还包括在途工作如何停、对端如何获知、残留数据如何处置，以及下一次操作是否会继承旧状态。
- 哈希 userId 仍然每个用户一个取值，不会降低基数；把 IP、版本完整 commit 与动态 TURN host 组合会指数增长。
- 失败被压成一个布尔值，调用方无法区分可重试、需用户介入与永久拒绝，最终形成无限循环。
- 降级路径从未压测，主路径故障时所有流量同时进入更慢、更昂贵的后备方案。
把测试跑成闭环
测试不能以“最后成功了”结束。还要测量经历了多少次副作用、等待多久、是否泄露内容，以及失败后再次执行能否从干净基线开始。
- 在测试环境生成十万用户和随机错误文本，采集器必须保持固定序列数量、报告丢弃计数并让 CI 标记违规标签。
- 让刷新、取消、超时和远端完成在同一调度窗口发生，断言系统只产生一个终态和一次副作用。
- 对日志和埋点做字段白名单检查，证明内容载荷、密钥、完整 IP 与用户可识别信息不会离开设备。
最终结果应同时满足正确性、可恢复性和可解释性。任何一项只能依赖刷新页面或工程师猜测，都说明协议闭环仍不完整。