分片上传核心是利用File.slice切片并控制并发：每片5MB，限3路并发，带唯一标识与超时；fetch/XHR选型需权衡进度监听与中止可靠性；服务端须暂存、校验、合并分片并处理续传。
分片上传的核心是 File.prototype.slice 和并发控制
浏览器端无法直接把一个大文件“拆开传”，必须靠 JavaScript 主动切片。关键不是 HTML5 本身支持分片，而是它提供了 File 对象和 Blob.prototype.slice 方法，让你能按字节范围提取子块。实际上传时，每一片都是独立的 FormData 请求，服务端需配合做合并与
-
file.slice(start, end)返回新Blob，注意参数是字节偏移量（不是数组下标），且end不包含在内 - 推荐每片大小设为
1024 * 1024 * 5（5MB），太大易超时，太小则 HTTP 开销占比高 - 不能直接对
input[type="file"].files[0]调用.slice()后立刻上传——要等FileReader或fetch拿到二进制内容再发，否则会传空
如何避免并发请求压垮浏览器或服务端
无节制并发（比如同时发 100 个 fetch）会导致连接池耗尽、内存暴涨、服务端拒绝响应。必须限制并发数，并确保失败后可重试。
- 用
Promise.allSettled+ 队列控制：每次只允许最多3个请求在飞 - 每个分片请求需带唯一标识，如
chunkIndex、totalChunks、fileHash（可选），方便服务端去重和排序 - 上传失败的分片应记录索引，后续只重传失败项，不要整个重来
- 务必设置
timeout（例如abortController.timeout = 60_000），防止挂起请求阻塞队列
XMLHttpRequest 和 fetch 在分片上传中的实际差异
两者都能用，但行为细节影响稳定性。尤其在中断续传、进度监听、错误捕获上差别明显。
-
fetch默认不支持上传进度，必须用ReadableStream+TransformStream手动包装Blob才能监听，复杂度高；而XMLHttpRequest.upload.onprogress开箱即用 -
XMLHttpRequest的abort()更可靠，fetch中AbortController对已发出请求的终止效果依赖浏览器实现，部分旧版可能无效 - 如果服务端要求带自定义 header（如
X-Upload-Chunk-Index），fetch允许直接写；XMLHttpRequest需确认服务端是否允许该 header（CORS 预检可能失败）
服务端必须处理的三个关键逻辑点
前端只是“发得出去”，真正决定分片上传成败的是服务端能否正确识别、暂存、合并、清理。
- 收到分片后，不能直接写入最终文件，应以
{fileId}_{chunkIndex}命名暂存到临时目录（如/tmp/uploads/abc123_0） - 合并前必须校验所有分片是否齐全（
chunkIndex是否连续、总数是否等于totalChunks），并建议对每个分片算md5或sha256与前端传来的比对 - 合并完成后立即删除所有分片文件；若合并失败，应保留分片至少 24 小时，供前端发起续传
const uploadChunk = async (blob, index, fileId, total) => {
const formData = new FormData();
formData.append('chunk', blob, `chunk_${index}`);
formData.append('chunkIndex', index);
formData.append('totalChunks', total);
formData.append('fileId', fileId);
const controller = new AbortController();
setTimeout(() => controller.abort(), 60_000);
const res = await fetch('/upload/chunk', {
method: 'POST',
body: formData,
signal: controller.signal
});
if (!res.ok) throw new Error(Chunk ${index} failed: ${res.status});
};
分片上传真正的复杂点不在切片本身，而在断网、刷新、重复提交、服务端崩溃这些边界场景下的状态一致性。前端缓存 fileId 和已成功上传的 chunkIndex 列表，比追求“一次传完”更重要。
