把它做成生产功能之前，需要先拆开协议事实、产品承诺和运行成本，三者混在一起很容易得到错误结论。 固定为一块在途会在高 RTT 链路浪费带宽，固定为数百 MB 又会挤压浏览器内存并阻塞控制消息。窗口代表允许尚未确认的数据总量，应随路径反馈变化而不是只看单块大小。
文件传输要同时对账发送偏移、接收落盘、分块校验和双方终态。进度条到达百分之百，只能说明字节进入队列，不能证明文件完整可用。
落地方案的关键部件
先从数据和协议能保证的事实出发，再决定界面承诺。下面的规则都应有明确所有者、边界值和兼容策略，不能只存在于某次代码评审的口头共识里。
- 以保守初始窗口启动，稳定确认后按 RTT 周期小幅增长而不是指数放大。
- 超时、重复缺口或 bufferedAmount 持续高水位时快速收缩窗口。
- 设置设备级硬上限与控制消息保留空间，移动端和桌面端可以使用不同档位。
自适应窗口的目标不是追逐瞬时峰值，而是在不同 RTT 和设备能力下保持稳定吞吐、有限内存与快速控制响应。
别让错误假设进入生产
最值得优先排查的是会静默留下错误事实的故障：界面看似恢复，底层队列、权限或计数却已分叉。这类问题通常在下一次动作才暴露。
- 把应用 ACK 延迟误判为网络拥塞，接收端写盘慢时窗口不断归零。
- 窗口按块数而不是字节计算，块大小切换后实际内存突然翻倍。
- 网络切换仍保留旧大窗口，新路径建立瞬间产生严重突发流量。
发布闸门应该检查什么
验证时同时观察两端状态、持久化记录和可观测指标。单看某个按钮或一次接口响应，无法证明整个闭环成立。
- 用固定带宽改变 RTT，确认窗口能填满带宽时延积而控制延迟仍受限。
- 分别限制接收端 CPU、存储和网络，确认系统能区分瓶颈并稳定收敛。
- 传输中切换直连与 TURN，记录窗口重置、恢复时间和内存峰值。
最终结果应同时满足正确性、可恢复性和可解释性。任何一项只能依赖刷新页面或工程师猜测，都说明协议闭环仍不完整。