前端断点续传如何设计？分片上传需要注意哪些问题？

简化版

断点续传通常把大文件切成多个 chunk，前端计算文件标识，询问服务端已上传分片，只上传缺失分片，最后通知服务端合并。它解决大文件上传失败后从头再来的问题。关键点包括分片大小、并发数、文件 hash、秒传、暂停恢复、失败重试、进度统计、服务端合并和清理临时分片。安全上不能信任前端 hash，服务端仍要校验。

详细版

断点续传常见流程如下：

步骤	说明
切片	使用 Blob.slice 生成 chunk
标识	根据文件名、大小、hash 生成 fileId
查询	服务端返回已上传分片
上传	并发上传缺失 chunk
合并	服务端按顺序合并并校验

function createChunks(file: File, size = 2 * 1024 * 1024) {
  const chunks: Blob[] = []
  for (let start = 0; start < file.size; start += size) {
    chunks.push(file.slice(start, start + size))
  }
  return chunks
}

断点续传不是只切片上传，核心在“服务端知道哪些分片已经成功”。

完整版教学

一、为什么需要断点续传

大文件上传时间长，弱网、切后台、刷新页面、网关超时都可能导致失败。如果每次失败都从头上传，用户体验很差，服务端也浪费带宽。

断点续传让成功上传的分片可以复用。

二、基本流程

前端先切片，然后计算文件标识，向服务端询问上传状态。服务端告诉前端哪些分片已存在，前端只上传缺失部分。

全部分片完成后，前端发合并请求，服务端按分片序号合并。

三、文件标识怎么做

文件标识可以基于文件名、大小、最后修改时间和内容 hash。内容 hash 更可靠，但大文件计算 hash 本身耗时，可以放到 Web Worker。

标识方式	优点	缺点
名称 + 大小	快	可能碰撞
内容 hash	准	计算耗时
服务端 uploadId	简单	首次必须创建会话

四、并发和重试

分片上传可以并发，但不能无限并发。常见并发数是 3 到 6，根据网络和服务端能力调整。

失败分片可以单独重试，重试次数耗尽后暂停整个上传，并允许用户继续。

async function uploadChunk(chunk: Blob, index: number) {
  const form = new FormData()
  form.append('chunk', chunk)
  form.append('index', String(index))
  return fetch('/upload/chunk', { method: 'POST', body: form })
}

五、进度统计

整体进度不能只按完成分片数算，因为最后一个分片可能更小，不同分片上传速度也不同。

更准确的方式是累计每个分片已上传字节数，除以文件总大小。

六、服务端职责

服务端要做：

保存上传会话。
校验分片序号和大小。
防重复分片。
合并后校验文件完整性。
清理过期临时分片。
权限校验和容量限制。

前端 hash 只是辅助，服务端不能盲信。

七、常见误区与追问

误区：前端切片就等于断点续传。 还需要服务端记录已上传分片并支持合并。
误区：分片越小越好。 太小请求多，开销大；太大失败重传成本高，需要折中。
误区：前端 hash 可以完全信任。 攻击者可伪造，服务端必须重新校验关键数据。
追问：如何实现秒传？ 服务端根据文件 hash 判断已有完整文件，直接返回成功。
追问：暂停上传怎么做？ 停止调度新分片，并 abort 正在上传的请求。
追问：大文件 hash 卡页面怎么办？ 使用 Web Worker 分块计算，避免阻塞主线程。

八、加强记忆

断点续传记成“切片、查缺、补传、合并”。前端管切片和调度，服务端管状态和校验；并发、重试、暂停、清理都是完整方案的一部分。

简化版

详细版