分片上传是处理大文件的稳法：用file.slice()切块、逐块发送并监听进度，失败只重传对应块；超大文件可用fetch+ReadableStream流式上传，需手动设Content-Range头；同时需禁用多选预加载、防重复提交、暂停/恢复上传及服务端原子合并校验。
用 XMLHttpRequest 分片上传，别直接 FormData.append(file)
浏览器直接上传几百 MB 甚至 GB 级文件时卡死，本质是把整个 File 对象一次性读进内存再发出去。分片才是稳法：用 file.slice() 切成 2–5 MB 每块，逐块发，每块发完才切下一块。
关键点：
-
slice()是File（继承Blob）原生方法，支持start、end字节偏移，不复制数据，不占额外内存 - 必须设置
xhr.upload.onprogress监听单块进度，否则看不出上传中 - 服务端需能接收
chunk、识别upload_id、chunk_index、total_chunks并合并 - 前端要处理失败重传（比如某块 500 错误后只重发那一块，不是全重）
启用 fetch + ReadableStream 流式上传（Chrome 109+ / Edge 109+）
比 XMLHttpRequest 更底层、更可控，适合真正超大文件（如 10 GB 视频），避免内存峰值。
实操要点：
立即学习“前端免费学习笔记（深入）”；
- 用
file.stream()获取可读流，再用stream.getReader()分块读取Uint8Array - 每次
reader.read()返回{ value, done }，value是二进制片段，直接fetchbody 发送 - 必须手动拼接
Content-Range头（如bytes 0-1048575/1073741824），服务端靠它定位写入位置 - 注意：Safari 和旧版 Firefox 不支持
ReadableStream上传，得降级到分片XHR
const stream = file.stream();
const reader = stream.getReader();
let offset = 0;
while (true) {
const { done, value } = await reader.read();
if (done) break;
await fetch('/upload', {
method: 'POST',
headers: {
'Content-Range': `bytes ${offset}-${offset + value.length - 1}/${file.size}`
},
body: value
});
offset += value.length;
}禁用 input[type="file"] 的默认多选全加载行为
用户一次选 10 个 2 GB 文件，input.files 看似只是引用，但某些浏览器（尤其移动端 WebView）会在你调用 file.arrayBuffer() 前就预加载元数据甚至触发缩略图解析，导致卡顿。
缓解方式：
- 用
event.currentTarget.files.item(0)只取第一个，或显式用Array.from(e.target.files).slice(0, 1) - 上传前不调任何同步读取方法（如
file.text()、file.arrayBuffer()），等分片循环里再按需读 - 加
accept="video/*,application/pdf"限制类型，减少误选大文件概率 - 用
webkitdirectory或directory属性时务必校验file.size，跳过 >2GB 的项
上传中禁止用户重复点击、关页、切 Tab —— 但别用 alert 拦
用户狂点“上传”按钮导致并发请求堆积，或切走页面中断上传，是卡顿的间接原因。不能靠弹窗阻塞，要用轻量级控制。
推荐做法：
- 按钮置
disabled，同时加data-uploading="true"标记，防止 JS 逻辑重复触发 - 监听
beforeunload，仅当uploadingChunks.length > 0时返回提示文案（现代浏览器只显示默认提示） - 用
Page Visibility API：若document.hidden === true且正在上传，暂停当前块、保存offset，切回时继续 - 别用
localStorage存整个File，存{ uploadId, offset, fileName, totalSize }就够恢复
分片逻辑和流式传输本身不难，真正容易被忽略的是服务端 chunk 合并时的原子性——比如某块写到一半崩溃，没写完的临时文件残留，下次上传同名文件就可能拼出损坏文件。稳法的最后一步，永远是服务端的断点续传校验和清理策略。
