把它做成生产功能之前，需要先拆开协议事实、产品承诺和运行成本，三者混在一起很容易得到错误结论。 浏览器离线开关只能制造全断，无法区分信令与媒体、入站与出站。测试需要在不同层控制 WebSocket 帧、TURN 包和应用块。
测试要把状态机、故障注入和真实浏览器组合起来。确定性用例守住已知契约，随机时序寻找竞态，失败 seed 和两端轨迹必须保存成永久回归。
落地方案的关键部件
先把下面几项写成可评审的规则，而不是散落在回调和界面判断里。规则越清楚，后续扩容、兼容和排错越少靠猜。
- 基础设施提供延迟、抖动、带宽、丢失与方向配置；协议测试钩子按 messageId 丢弃或重复，所有随机计划保存 seed 便于重放。
- 为状态写出唯一所有者、版本号和终态；任何回调只能修改自己创建的版本。
- 资源释放是协议的一部分：定时器、句柄、队列和临时数据都要在终态中可重复清理。
“浏览器网络故障注入：丢包、乱序、延迟与单向黑洞怎么测”的交付标准是正常路径可用、异常路径收敛、资源有界，并且用户能理解系统为何采用当前状态。 这样得到的不是演示代码，而是能解释、能降级、能回滚的生产能力。
别让错误假设进入生产
不要把异常路径理解成弹一次提示。它还包括在途工作如何停、对端如何获知、残留数据如何处置，以及下一次操作是否会继承旧状态。
- 只在 localhost 用 DevTools 限速不会影响 UDP WebRTC；不可记录 seed 的随机丢包又让一次失败无法重现。
- 失败被压成一个布尔值，调用方无法区分可重试、需用户介入与永久拒绝，最终形成无限循环。
- 指标标签直接包含用户或任务标识，既制造高基数成本，也让诊断数据泄露不必要的身份信息。
发布闸门应该检查什么
用已知输入和可控故障建立金样本，然后把线上低基数指标与测试结果对齐。只有指标能提前识别同类退化，验证才真正延伸到生产。
- 建立故障矩阵分别作用于信令、DataChannel 和媒体，在同一 seed 下重复十次并验证状态轨迹与超时边界一致。
- 用乱序、重复和延迟消息驱动状态机，确认旧版本被丢弃且显式停止不会被自动恢复覆盖。
- 分别覆盖直连、中转、弱网、后台标签页和移动端，报告不能只给平均值或一次成功截图。
可以上线的标准是：用户知道当前发生了什么，系统在异常后能停止或恢复，资源不会无界增长，运维也能从最小必要证据定位阶段。