断点续传核心是分片上传加服务端校验；前端用File.slice()分片并携带唯一identifier（文件名+最后修改时间+序号）标识每片，上传前先查询服务端已存分片索引，仅重传失败分片，服务端需幂等接收、校验完整性、合并并持久化identifier映射关系。
断点续传核心是分片上传 + 服务端校验
纯前端无法真正“断点续传”，因为浏览器关闭后 XMLHttpRequest 或 fetch 连接必然中断，且无法恢复上传状态。真正的断点续传必须由前端分片、记录已传块、服务端持久化校验（如 MD5/SHA1 或分片索引），再在重试时跳过已成功上传的分片。
前端分片上传的关键步骤
用 File.slice()（或现代 ArrayBuffer.slice()）切文件，配合 FormData 逐片提交。关键不是“怎么切”，而是“怎么标识每一片”和“怎么知道哪片传过了”：
- 每片需携带唯一标识：建议用
file.name+file.lastModified+ 分片序号（chunkIndex）拼成 key，避免同名文件覆盖 - 上传前先发请求查服务端已存分片列表（如
/api/upload/check?filename=xxx&total=12），返回已上传的[0,2,3,5]索引数组 - 只对未上传的索引发起
POST /api/upload/chunk，附带chunkIndex、totalChunks、identifier字段 - 上传失败时保留当前索引，不重置计数器；用户点击“继续”后从第一个失败索引起重试
const uploadChunk = async (file, index, total, identifier) => {
const blob = file.slice(index * CHUNK_SIZE, (index + 1) * CHUNK_SIZE);
const formData = new FormData();
formData.append('chunk', blob);
formData.append('chunkIndex', index);
formData.append('totalChunks', total);
formData.append('identifier', identifier);
try {
await fetch('/api/upload/chunk', { method: 'POST', body: formData });
return { success: true };
} catch (err) {
return { success: false, index };
}
};
服务端必须支持分片合并与去重
前端传来的只是“块”，服务端必须能：接收分片 → 存临时目录 → 校验完整性 → 合并 → 清理临时文件。常见坑：
- 没做分片幂等处理：同一
chunkIndex重复提交导致文件损坏 → 必须用identifier + chunkIndex做唯一键，二次上传直接 200 跳过 - 合并时机错误：收到最后一片就立即合并 → 应先校验所有分片是否齐备（查数据库或临时目录文件数），再触发合并
- 没存
identifier映射关系：用户换设备重试时无法识别是同一文件 → 需将identifier和原始文件名、大小、总片数存在 DB 或 Redis 中，有效期建议 24h
浏览器兼容性与大文件限制
File.slice() 在 IE10+ 和所有现代浏览器都支持，但注意：
立即学习“Java免费学习笔记（深入）”；
- IE10/11 不支持
Blob.slice()，要用File.slice()（二者原型一致） - Chrome 对单个
FormData的blob大小无硬限，但内存占用高；建议单片控制在 2–5MB，避免卡死 UI - 移动端 Safari 对长时间运行的上传容易被系统挂起 → 必须加心跳保活（如每 30s 发一次
/api/upload/keepalive?identifier=xxx） - 不要依赖
onprogress计算百分比：它只反映当前分片进度；总进度需按(已成功分片数 / totalChunks) * 100算
真正难的不是切片，是前后端对“已传状态”的共识同步。很多项目卡在服务端没存分片记录，或前端缓存了错误的已传索引 —— 这类问题上线后几乎无法 debug，只能靠日志埋点和 identifier 全链路追踪。
