大文件上传

大文件上传的核心问题不是“怎么把文件发出去”，而是“上传过程能不能可靠、可恢复、可控”。

为什么普通上传不够

文件很大时，直接一次性上传常见问题有：

• 中途断网就要全部重传
• 上传时间过长，失败成本高
• 浏览器和服务端压力更大
• 很难做稳定的进度和恢复机制

所以大文件上传通常不会只靠一次请求完成。

最常见方案：分片上传

分片上传表示：

• 前端先把文件切成多个小块
• 每块单独上传
• 服务端最终再合并这些块

可以把它理解成：把一个大事务拆成多个可恢复的小事务。

一个基本流程

常见流程通常是：

1. 前端切片
2. 为文件和切片生成标识
3. 按一定并发数上传切片
4. 服务端记录已上传分片
5. 全部分片完成后触发合并

切片大小怎么选

切片不是越大越好，也不是越小越好。

• 太小：请求过多，调度成本高
• 太大：单片失败重传代价高

常见经验值通常在几 MB 级别，再根据网络环境和服务端能力调整。

为什么要有文件标识

服务端要知道：

• 这些分片属于哪个文件
• 当前分片是第几块
• 哪些块已经传过了

所以通常会给每个上传任务准备：

• 文件级标识
• 分片索引

更进一步还会用文件内容 hash 作为更稳定的标识。

断点续传是怎么做到的

断点续传本质上不是“浏览器自动记住了进度”，而是：

• 前端重新询问服务端哪些分片已经上传
• 只补传缺失的部分

所以它依赖的是前后端共同维护分片状态，而不是单靠前端。

秒传是什么

所谓“秒传”，通常不是文件真的没传，而是：

• 前端先计算文件标识
• 服务端判断这个文件是否已经存在
• 如果存在，就直接复用已有结果

这能避免同一个文件被重复上传。

常见优化点

限制并发

不要一次性把所有分片同时上传。通常要控制并发数，避免：

• 浏览器请求过多
• 服务端压力过高
• 上传失败率升高

Worker 切片或算 hash

文件切片和计算 hash 都可能比较耗时，必要时可以放到 Web Worker，减少主线程卡顿。

分片进度和总进度

大文件上传通常不只是一条进度条：

• 单分片有自己的上传进度
• 整个文件还要有总进度

页面设计时要先明确展示哪一层。

最容易忽略的边界

大文件上传不只是前端题，还要考虑服务端策略，例如：

• 分片保存多久
• 合并失败如何回滚
• 重复上传如何清理
• 文件校验放在哪一步

所以这类方案本质上是前后端协同设计。

使用建议

• 文件明显偏大时，优先考虑分片上传。
• 需要恢复能力时，前后端都要支持分片状态查询。
• 需要更好体验时，再补上秒传、Worker、限并发和总进度设计。
• 不要把大文件上传只理解成“前端把文件切开”。