好的实现不会依赖用户反复刷新碰运气，而会让每个阶段有明确输入、输出、超时和终态。 只提供 send 回调的 mock 会让所有写入瞬间成功，完全跳过背压。好的 fake 维护发送缓冲，按配置带宽排空并异步触发 bufferedamountlow。
测试要把状态机、故障注入和真实浏览器组合起来。确定性用例守住已知契约，随机时序寻找竞态，失败 seed 和两端轨迹必须保存成永久回归。
先定义系统契约
落地时要把关键选择变成稳定契约：输入如何校验、状态由谁推进、资源何时释放、旧版本如何降级。只有这样，后续优化才不会改变原有语义。
- 状态覆盖 connecting/open/closing/closed，send 在非法状态抛出；计划器支持大小上限、到达顺序与半关闭，并记录所有帧供断言。
- 所有输入都设置大小、次数和时间预算，并在超限时返回可操作的稳定错误码。
- 上线参数必须有保守默认值、服务端上限和灰度开关，不能把浏览器传来的数字直接当作资源预算。
“Fake DataChannel 怎么写才不把真实背压和关闭语义测没”的交付标准是正常路径可用、异常路径收敛、资源有界，并且用户能理解系统为何采用当前状态。 这样得到的不是演示代码，而是能解释、能降级、能回滚的生产能力。
哪些情况会破坏契约
失败路径需要与成功路径共享同一套状态模型。只弹一个错误提示却不释放资源、不传播终态，下一次恢复就会继承脏状态。
- 同步触发 onmessage 会改变真实浏览器的任务顺序并隐藏竞态；关闭后静默接受 send 又让资源泄漏测试失真。
- 刷新或网络切换同时触发两条恢复路径，重复副作用被误当成两次真实用户操作。
- 只在理想数据量下测试，真实的大文件、长会话或高并发会越过隐含上限并产生级联故障。
如何逐条验证契约
用已知输入和可控故障建立金样本，然后把线上低基数指标与测试结果对齐。只有指标能提前识别同类退化，验证才真正延伸到生产。
- 让同一协议测试分别运行 fake 与两个真实浏览器，对照帧序列、背压暂停、取消延迟和关闭异常，约束替身漂移。
- 在操作中途断网、切换网络并恢复，核对两端状态、持久化记录和资源计数最终一致。
- 对日志和埋点做字段白名单检查，证明内容载荷、密钥、完整 IP 与用户可识别信息不会离开设备。
最终结果应同时满足正确性、可恢复性和可解释性。任何一项只能依赖刷新页面或工程师猜测，都说明协议闭环仍不完整。