断点续传核心是跳过已传切片，需前后端协同：用File.slice()按ceil(file.size/shardSize)分片，end设为file.size防丢末尾；以文件MD5为唯一fileId查服务端已传索引；localStorage存进度须防隐私模式、多标签冲突及容量超限。
断点续传在前端不能靠 HTTP 协议原生支持（HTTP/1.1 的 Range 仅用于下载），必须由前后端协同设计实现。核心不是“恢复连接”，而是“跳过已传切片”——靠文件指纹 + 切片状态记录 + 分片上传完成确认。
怎么用 File.slice() 正确切片而不丢数据
切片不是简单按固定字节数等分，关键要对齐边界、处理末尾不整除情况：
-
slice(start, end)的end是「不包含」的，所以file.slice(0, 1024 * 1024)是前 1MB，file.slice(1024 * 1024, 2 * 1024 * 1024)是第 2MB，以此类推 - 最后一片的
end必须设为file.size，否则会漏掉末尾字节；错误写法：file.slice(lastStart, lastStart + shardSize)（可能越界） - 不要用
Math.floor(file.size / shardSize)算片数，要用Math.ceil(file.size / shardSize)，否则少算一片 - 切片顺序必须严格从 0 开始递增，服务端合并时依赖这个索引
为什么必须计算文件 MD5，只靠文件名+大小不行
文件名和大小极易重复，比如用户反复修改后保存同名文件、不同设备导出同尺寸截图。服务端仅凭这两项无法区分是否为同一上传任务：
- 浏览器端用
spark-md5计算整个文件的 hash（非逐片拼接），作为唯一fileId - 上传前先调接口查
fileId对应的已传切片列表，返回uploadedChunks: [0, 1, 3]就跳过这些索引 - 如果服务端没存该
fileId，说明是全新上传，从 0 开始 - localStorage 存的键也必须是
fileId，而不是fileName + size
XMLHttpRequest 上传切片时怎么避免 413 或超时
切片本身是小 Blob，但若携带冗余字段或未设请求头，仍可能被 Nginx/Apache 拦截或触发网关超时：
立即学习“前端免费学习笔记（深入）”；
- FormData 中只 append 必需字段：
chunk（Blob）、chunkIndex、totalChunks、fileId，去掉注释、时间戳等无关字段 - 服务端接收接口必须显式允许大请求体：Nginx 要配
client_max_body_size 10M（按单片大小设，不是总文件大小） - 禁用 XMLHttpRequest 的默认
Content-Type（会带 boundary），让浏览器自动设置；手动设multipart/form-data反而易出错 - 上传前检查
onerror和onabort，网络中断时不要立即重试，先等几秒再查服务端状态
localStorage 存进度有哪些隐藏风险
看似简单的本地存储，实际在多标签、隐私模式、存储满时行为差异极大：
- 隐私模式下
localStorage是临时的，关窗口即清空 —— 必须在上传开始前弹提示：“请勿使用无痕窗口” - 多个标签页同时上传同一文件时，
localStorage不同步，可能互相覆盖进度；需加锁机制（如用localStorage.setItem('uploading', 'true')做简易互斥） - 超过 5MB 容量限制会抛
QuotaExceededError，应捕获并 fallback 到sessionStorage或内存缓存（但刷新即失） - 上传成功后必须调
localStorage.removeItem(fileId)，否则下次选同文件仍读到旧状态
真正难的不是切片或发请求，而是让服务端能原子性地确认“某片已存且不可重复写入”，以及前端能在任意中断点（页面崩溃、断电、关机）后精准恢复索引。这两处没对齐，断点续传就只是个有漏洞的乐观假设。
