工程上最危险的不是完全不可用，而是在理想环境里正常、进入真实网络和真实数据量后悄悄失去边界。 浏览器通常不暴露温度，但持续吞吐下降、编码时间上升、长任务和电池状态可形成间接信号。目标应是稳定 goodput，而非前 30 秒峰值。
性能优化先定义用户等待的完整区间，再拆分 CPU、队列、网络和持久化阶段。平均值会掩盖真正流失用户的尾延迟，优化必须比较 p95/p99 与资源成本。
工程边界与取舍
落地时要把关键选择变成稳定契约：输入如何校验、状态由谁推进、资源何时释放、旧版本如何降级。只有这样，后续优化才不会改变原有语义。
- 移动端默认限制哈希 Worker 和并行文件数；编码时间持续超预算时逐级降帧率与分辨率，在低电量或后台明确暂停可延后工作。
- 为状态写出唯一所有者、版本号和终态；任何回调只能修改自己创建的版本。
- 兼容性通过显式能力协商决定，旧客户端得到可解释的降级路径，而不是进入半可用状态。
“移动端热降频：速度先快后慢不一定是网络问题”的交付标准是正常路径可用、异常路径收敛、资源有界，并且用户能理解系统为何采用当前状态。 这样得到的不是演示代码，而是能解释、能降级、能回滚的生产能力。
生产环境会怎样出错
最值得优先排查的是会静默留下错误事实的故障：界面看似恢复，底层队列、权限或计数却已分叉。这类问题通常在下一次动作才暴露。
- 算法把热降频误判为网络拥塞后缩小窗口，网络恢复也无法提速；同时提高编码和哈希并发会形成相互争抢。
- 只修正界面状态而没有清理底层资源，下一次操作继承队列、锁或过期凭据并再次失败。
- 只在理想数据量下测试，真实的大文件、长会话或高并发会越过隐含上限并产生级联故障。
把测试跑成闭环
验证时同时观察两端状态、持久化记录和可观测指标。单看某个按钮或一次接口响应，无法证明整个闭环成立。
- 在真实手机连续运行 30 分钟直连与 TURN 文件加屏幕共享，按时间记录 goodput、encode time、帧率、电量与机身温感代理。
- 让刷新、取消、超时和远端完成在同一调度窗口发生，断言系统只产生一个终态和一次副作用。
- 用故障注入验证告警先于用户投诉触发，并确认值班人员能从有限证据定位到具体阶段。
最终结果应同时满足正确性、可恢复性和可解释性。任何一项只能依赖刷新页面或工程师猜测，都说明协议闭环仍不完整。