前端大文件上传为什么会卡住：分片、并发窗口与断点续传的架构取舍

上传一个 800MB 的视频时，页面上的进度条停在 37% 并不一定是网络断了。更常见的原因是浏览器同时发出了太多分片请求，某个失败请求没有退出队列，后面的任务一直等着；如果用户刷新页面，已经成功的部分又被当成从零开始。比较稳的做法是把文件切成固定大小的分片，用有限并发窗口上传，并让服务端返回已接收分片清单，刷新后只补缺口。

大文件上传卡住的核心诱因很少是带宽跑满，大多是无节制的并发请求打满浏览器连接池、单点失败阻塞整个队列、没有落盘校验机制导致断点恢复时重传全部内容。用分片切割任务、固定并发槽控住峰值流量、靠服务端返回的已传分片清单做恢复，是多数业务场景下性价比最高的落地方案。

一次性上传为什么在大文件场景下撑不住

把整个 File 直接放进一个 fetch 请求，代码很短，却把三个问题揉成了一个长事务：连接断开时无法判断已经传了多少，浏览器或网关的请求体限制可能提前截断，重试时还要重新发送完整文件。

切片并不会自动解决问题。假设每片 8MB，800MB 文件会变成 100 个任务；如果用 Promise.all 一口气启动 100 个请求，连接池、内存和服务端临时文件占用都会突然升高。真正需要控制的是“同时在飞的任务数”，而不是只看文件总大小。

分片模型先把文件变成可追踪的任务

客户端至少要给每个分片一个稳定身份。简单项目可以使用文件指纹、分片序号和总片数拼出上传会话；生产项目通常还会把文件大小、修改时间或前端计算的哈希加入指纹，避免两个同名文件互相覆盖。

const PART_SIZE = 8 * 1024 * 1024;

function makeParts(file) {
  const parts = [];
  let index = 0;
  for (let start = 0; start 

这里的 index 必须从 0 连续递增，最后一片允许小于 8MB。服务端不要按请求到达顺序拼接，而应按会话 ID 和分片序号写入临时文件夹，例如 uploads/{uploadId}/000042.part，这样并发完成顺序变化也不会破坏文件。

并发窗口比“越多越快”更重要

小文件可以并发 3～4 片；如果每片都较大，继续加到 12 个并发，通常只是让失败重试变得更集中。下面的队列只保留固定数量的活动任务，某一片完成后才补下一片。

async function uploadParts(parts, uploadId, signal) {
  const limit = 4;
  let cursor = 0;
  const done = new Set();

  async function worker() {
    while (cursor 

这个最小实现有一个故意保留的边界：sendWithRetry 失败时应抛出错误，不能在 worker 内静默吞掉。否则进度条可能显示“全部完成”，服务端却缺一片。

重试、暂停和取消要有明确的状态边界

单个分片的网络错误适合做有限重试，例如 3 次，间隔 500ms、1s、2s。服务端返回 4xx 时不要盲目重试，文件过大、会话过期和校验失败都应该回到用户可见的错误状态。

async function sendWithRetry(part, uploadId, signal) {
  for (let attempt = 0; attempt = 400 && response.status  setTimeout(resolve, 500 * 2 ** attempt));
  }
}

暂停可以通过一个队列级别的停止标记实现；取消则调用 AbortController.abort()，并通知服务端清理临时分片。两者不要混为一谈：暂停要保留会话，取消通常意味着删除会话。

断点续传的关键是服务端清单，不是本地进度条

创建会话时，服务端返回 uploadId；查询接口返回已经落盘的分片序号。客户端恢复上传时先把这份清单放进 Set，只把缺少的分片送进并发队列。

const state = await fetch(`/api/upload/${uploadId}`).then(r => r.json());
const received = new Set(state.parts);
const pending = parts.filter(part => !received.has(part.index));

if (pending.length === 0) {
  await fetch(`/api/upload/${uploadId}/complete`, { method: 'POST' });
} else {
  await uploadParts(pending, uploadId, controller.signal);
}

完成接口还要再做一次服务端校验：分片数量是否齐全、每片大小是否符合约定、合并后的文件大小或哈希是否匹配。客户端显示 100% 只能说明请求都返回了，不能替代这一步。

上线前用三组指标判断架构是否真的变稳

先记录一次性上传的失败率、平均请求体大小和恢复耗时，再与分片方案对比。不要只看平均上传速度，P95 分片耗时、重试比例和临时文件夹占用更能暴露并发窗口的问题。

常见问题：大文件上传的几个边界

分片越小，上传一定越快吗？

不一定。分片太小会增加请求数量和服务端文件管理开销；可以从 5～10MB 试起，再根据网络质量和后端临时存储调整。

页面刷新后还能继续上传吗？

可以，但必须保留文件指纹与 uploadId，并向服务端查询已完成分片。只把百分比存到 localStorage 无法判断哪些分片真实落盘。

为什么不直接把并发数调到 16？

并发数受用户带宽、浏览器连接、服务端限流和临时磁盘共同约束。先用 3～4 个槽观察失败率，再按 P95 和重试比例做小步调整。

总结：把上传拆成可检查、可恢复的状态机

大文件上传的稳定性来自三个边界：分片让失败范围变小，并发窗口限制资源峰值，服务端清单让恢复动作有依据。前端可以先实现固定 4 并发和有限重试，再补齐暂停、取消、过期清理与合并幂等；这条路径比一开始堆满复杂功能更容易验证。