好的实现不会依赖用户反复刷新碰运气，而会让每个阶段有明确输入、输出、超时和终态。 一万个 4 KB 文件的数据量不大，却会触发一万次元数据、状态变更、摘要初始化和落盘事务。吞吐瓶颈从网络变成每项固定开销，单纯增加 DataChannel 块大小几乎没有帮助。
文件传输要同时对账发送偏移、接收落盘、分块校验和双方终态。进度条到达百分之百，只能说明字节进入队列，不能证明文件完整可用。
先定义系统契约
先把下面几项写成可评审的规则，而不是散落在回调和界面判断里。规则越清楚，后续扩容、兼容和排错越少靠猜。
- 一次发送整批 manifest，并用批次确认减少逐文件往返。
- 允许“打包但不压缩”形成连续流，同时保留原路径与摘要清单。
- 未打包时使用有限并发和公平队列，避免小文件洪水阻塞聊天与取消。
小文件优化要减少固定开销而不是只追求更大块。批量清单、有限并发和可索引打包可以兼顾速度、恢复粒度与交互响应。
哪些情况会破坏契约
不要把异常路径理解成弹一次提示。它还包括在途工作如何停、对端如何获知、残留数据如何处置，以及下一次操作是否会继承旧状态。
- 并发数按文件数无限增长，浏览器同时打开大量读取和哈希任务导致崩溃。
- 打包任务任一条目失败就要求整包重传，恢复粒度比原方案更差。
- UI 为每个块更新每个文件的进度，主线程绘制成本超过传输成本。
如何逐条验证契约
用已知输入和可控故障建立金样本，然后把线上低基数指标与测试结果对齐。只有指标能提前识别同类退化，验证才真正延伸到生产。
- 用相同总大小的一个大文件与十万个小文件对比 CPU、事务数和控制延迟。
- 在打包流中损坏中间条目，确认索引能定位并只修复必要范围。
- 取消一个文件、一个批次和整个任务，确认三种作用域不会互相误伤。
最终交付标准应当是：正常路径足够快，异常路径能够收敛，用户意图不会被自动恢复覆盖，运维人员也能从有限而安全的证据定位问题。