工程上最危险的不是完全不可用，而是在理想环境里正常、进入真实网络和真实数据量后悄悄失去边界。 浏览器带宽估计主要服务 RTP 拥塞控制，数值可能缺失、滞后或受媒体探测影响。DataChannel 还要观察 bufferedAmount 与应用 ACK goodput。
性能优化先定义用户等待的完整区间，再拆分 CPU、队列、网络和持久化阶段。平均值会掩盖真正流失用户的尾延迟，优化必须比较 p95/p99 与资源成本。
工程边界与取舍
这项能力横跨客户端、网络与服务端，局部最优很容易制造全局故障。工程决策需要同时约束两端行为、持久化事实和运维预算。
- 每秒采样并按 candidate-pair ID 分段，路径变化重置基线；媒体编码上限缓慢跟随估计，文件窗口以真实确认吞吐和控制延迟为准。
- 把协议事实、用户意图和自动恢复分层；自动化只能恢复事实，不能推翻用户明确选择。
- 重试必须带幂等键、退避和截止时间；超过截止时间后建立新任务，而不是继续复活旧回调。
“WebRTC 带宽估计怎么看：别把瞬时码率当可用吞吐”的交付标准是正常路径可用、异常路径收敛、资源有界，并且用户能理解系统为何采用当前状态。 这样得到的不是演示代码，而是能解释、能降级、能回滚的生产能力。
生产环境会怎样出错
失败路径需要与成功路径共享同一套状态模型。只弹一个错误提示却不释放资源、不传播终态，下一次恢复就会继承脏状态。
- 把 bytesSent 差值直接称为带宽会包含重传与队列释放；路径切换后沿用旧平均又会过度发送或长期保守。
- 只修正界面状态而没有清理底层资源，下一次操作继承队列、锁或过期凭据并再次失败。
- 降级路径从未压测，主路径故障时所有流量同时进入更慢、更昂贵的后备方案。
把测试跑成闭环
验证需要先写预期状态轨迹，再执行故障注入。每个阶段同时核对用户可见结果、两端协议状态、持久记录和资源计数，才能证明闭环成立。
- 在限速、丢包和直连转 TURN 时对齐 stats、应用 ACK 与真实网络整形值，量化各信号的滞后和误差。
- 让刷新、取消、超时和远端完成在同一调度窗口发生，断言系统只产生一个终态和一次副作用。
- 发布前记录成功率、p50/p95/p99 延迟、错误分类和资源高水位，并为回退条件设定明确阈值。
最终结果应同时满足正确性、可恢复性和可解释性。任何一项只能依赖刷新页面或工程师猜测，都说明协议闭环仍不完整。