XMLHttpRequest 是断点续传唯一可行基础，因其支持 upload.onprogress、abort() 和自定义请求头（如 Range），但需服务端配合校验 offset 并持久化状态。
为什么 XMLHttpRequest 是断点续传的唯一可行基础
浏览器原生不支持直接读取文件写入位置或暂停上传流，fetch 也不暴露底层传输控制权。只有 XMLHttpRequest 提供 upload.onprogress、可手动中止（abort()）、且允许自定义请求头（如 Range），这是实现断点续传的前提。
关键限制：必须服务端配合 —— 上传前先发 HEAD 请求查 Content-Range 或用独立接口返回已上传字节偏移量，否则客户端无法知道从哪续。
- 服务端需保存每个文件的已上传字节长度（例如存在 Redis 或数据库里，key 为文件唯一标识
fileId） - 上传时在请求头带上
Upload-Offset: 12345，服务端校验后追加写入 - 若服务端不支持分片或
Range，断点续传实际不可行，强行“模拟”只是重传整个文件
File.prototype.slice() 怎么切出正确的分块并避免内存爆炸
大文件不能一次性读进内存再上传，必须分块（chunk）。但 slice() 返回的是 Blob，不是新文件对象，不会复制数据，只生成引用，所以安全。
常见错误是 chunk 大小设得太小（如 1KB），导致 HTTP 请求过多；或太大（如 100MB），卡住主线程且失败重试成本高。推荐 5–10MB。
立即学习“Java免费学习笔记（深入）”；
const chunkSize = 5 * 1024 * 1024; // 5MB let offset = 0;function uploadChunk(file) { const chunk = file.slice(offset, Math.min(offset + chunkSize, file.size)); const formData = new FormData(); formData.append('chunk', chunk); formData.append('offset', offset); formData.append('fileId', fileId);
const xhr = new XMLHttpRequest(); xhr.open('POST', '/upload/chunk', true); xhr.upload.onprogress = (e) => { if (e.lengthComputable) { const loaded = offset + e.loaded; const percent = (loaded / file.size) * 100; updateProgress(percent); } };
xhr.onload = () => { if (xhr.status === 200) { const res = JSON.parse(xhr.responseText); offset = res.offset; // 服务端返回实际写入位置（防并发冲突） if (offset < file.size) uploadChunk(file); // 继续下一块 else finishUpload(); } }; xhr.send(formData); }
进度条不准？检查这三处 XMLHttpRequest 的坑
进度条跳变、卡在 99%、甚至倒退，通常不是算法问题，而是对 XMLHttpRequest 生命周期理解偏差。
-
upload.onprogress只报告已发送到网络栈的字节数，不包含请求头、分块边界开销 —— 所以最终总和必然略小于file.size - 服务端响应体过大（比如返回完整文件信息 JSON）会触发
onload前的onprogress事件，误算成“上传进度”，必须用event.lengthComputable && event.target === xhr.upload严格过滤 - 没处理
onerror和onabort，导致失败后仍显示“正在上传”，掩盖真实状态
断点续传真正难的不是前端代码，而是文件唯一性与状态同步
用户换设备、清缓存、甚至只是刷新页面，前端就丢失 offset。必须靠服务端持久化状态，并用稳定 ID 关联。
别用 file.name + file.size 当 fileId —— 同名同大小文件极常见；也别依赖 File.lastModified，它精度低且可被篡改。
- 最佳实践：前端用
spark-md5或 Web Crypto API 计算文件前 2MB 的哈希（快速且抗碰撞），拼上完整 size 生成fileId - 每次上传前先
HEAD /upload/status?fileId=xxx，服务端返回Upload-Offset: 123456或404 - 服务端必须对同一
fileId的并发上传做互斥（Redis SETNX 或数据库行锁），否则 offset 覆盖导致数据错乱
这些逻辑一旦漏掉一环，断点续传就退化成“看起来能续，其实重传”。
