大文件分片断点续传，前后端的权衡与职责边界

最近帮团队重构了一版大文件分片上传，前后端在职责边界上的划分，稍微没理清楚就会变成互相妥协的烂摊子。

聊聊我比较推崇的做法和几个取舍点：

1. Hash 计算：前端用 Web Worker 计算避免阻塞 UI 是基础。但面对几十 G 的大文件，全量读完算 Hash 依然很吃性能。我们现在的折中是前端做“抽样 Hash + 文件基础元信息”做初筛，真正的全量校验放到服务端落盘后异步去做。
2. 断点状态的持有者：建议前端尽量保持“无状态”。断点续传依赖的已传分片索引，每次上传前直接找服务端拉取，而不是前端自己在 LocalStorage 或 IndexedDB 里维护一套。客户端只做纯粹的执行器，降低状态不一致的排查成本。
3. 分片合并的时机：前端显式调用 Merge 接口，还是后端收到最后一个 Chunk 后自动合并？自动合并虽然看起来少一次交互，但遇到网络重试、分片乱序到达时容易产生竞态。我们最终还是保留了前端显式调 Merge，逻辑清晰，容错更好控制。

全栈做多了就会发现，这种功能没有标准答案，本质是客户端计算能力和服务端 IO 压力之间的动态平衡。

大家在生产环境里，更倾向于把合并判定和状态维护放在哪一边？遇到了哪些比较恶心的边界情况，欢迎交流。