一项能力能否长期维护，不取决于演示是否成功，而取决于团队能否解释每个状态、每次重试和每一份残留数据。 控制消息决定任务是否继续和资源是否释放，它们的价值高于下一块数据。即使使用多个 DataChannel，它们仍可能共享同一个 SCTP association，因此还需要限制 bulk 队列并让调度器保留控制容量。
文件传输要同时对账发送偏移、接收落盘、分块校验和双方终态。进度条到达百分之百，只能说明字节进入队列，不能证明文件完整可用。
设计时必须回答的问题
实现之前先列出不可违反的不变量，再为性能与体验留出调节参数。参数可以灰度，身份、权限和终态规则不能在运行时随意漂移。
- 控制通道可靠有序且消息很小；bulk 通道按能力使用无序或部分可靠。
- 所有发送进入同一个优先级调度器，控制队列在每轮都能抢占 bulk。
- ACK 可聚合但有最大延迟，避免确认风暴也避免窗口长时间停住。
分通道不是终点，真正保证可用性的是统一的有界调度：控制能抢占，批量不饿死，任何一方取消都能迅速收敛。
边界情况不是附加项
不要把异常路径理解成弹一次提示。它还包括在途工作如何停、对端如何获知、残留数据如何处置，以及下一次操作是否会继承旧状态。
- 两个通道分别直接调用 send，bulk 循环仍可把浏览器底层缓冲塞满。
- 取消只改变本地 UI，没有带任务 ID 的可靠控制消息和对方确认。
- 控制调度无公平上限，大量心跳与 ACK 反过来让 bulk 永远得不到发送机会。
用证据确认它真的可用
测试不能以“最后成功了”结束。还要测量经历了多少次副作用、等待多久、是否泄露内容，以及失败后再次执行能否从干净基线开始。
- 在 bulk 高水位时发送取消、聊天和暂停，断言端到端延迟在明确上限内。
- 制造 ACK 突发和心跳风暴，确认 bulk 仍按最低保障速率前进。
- 与只有单通道的旧端互通，验证同一调度器能在一条通道内保持优先级。
可以上线的标准是：用户知道当前发生了什么，系统在异常后能停止或恢复，资源不会无界增长，运维也能从最小必要证据定位阶段。