一项能力能否长期维护，不取决于演示是否成功，而取决于团队能否解释每个状态、每次重试和每一份残留数据。 默认可靠有序适合不能丢失的控制消息，却会让一个丢包阻塞后续所有消息。部分可靠通道允许过期数据放弃重传，更适合很快会被新状态覆盖的光标、速率采样或可补洞文件块。
WebRTC 的判断依据必须来自两端状态、信令版本和实际选中的候选对。只看某个浏览器回调会遗漏 glare、ICE 切路与对端刷新造成的分叉。
设计时必须回答的问题
先把下面几项写成可评审的规则，而不是散落在回调和界面判断里。规则越清楚，后续扩容、兼容和排错越少靠猜。
- 身份、任务元数据、取消和完成确认使用可靠有序控制通道。
- 批量文件块可使用无序部分可靠通道，但必须有块 ID、缺口检测和选择性补发。
- 光标、带宽采样和正在输入状态以最新值为准，过期消息不值得长期重传。
通道可靠性是业务协议的一部分，不是性能开关。先定义消息能否丢、能否乱序、由谁补偿，再选择 DataChannel 参数和兼容策略。
边界情况不是附加项
不要把异常路径理解成弹一次提示。它还包括在途工作如何停、对端如何获知、残留数据如何处置，以及下一次操作是否会继承旧状态。
- 控制与大文件共用可靠有序通道，单个丢块让取消消息长时间无法到达。
- 把 maxRetransmits 设为零却没有应用补发，文件在弱网中静默损坏。
- 双方创建通道参数不一致或旧版本不支持新通道，协商成功后功能仍不可用。
用证据确认它真的可用
用已知输入和可控故障建立金样本，然后把线上低基数指标与测试结果对齐。只有指标能提前识别同类退化，验证才真正延伸到生产。
- 注入单块丢失，确认控制消息立即到达且文件协议只补缺失块。
- 在高延迟与乱序网络发送光标和进度，确认旧状态不会覆盖新状态。
- 与只支持单可靠通道的旧客户端互通，验证能力协商能安全降级。
最终交付标准应当是：正常路径足够快，异常路径能够收敛，用户意图不会被自动恢复覆盖，运维人员也能从有限而安全的证据定位问题。