断点续传核心是切片逻辑与状态一致性：末片必须用file.size为边界，切片总数用Math.ceil计算，fileId须基于内容MD5生成，上传前校验已传索引，每片带chunkIndex/totalChunks/fileId，单片≤5MB，URL防缓存，服务端需落盘后返回含确认字段的响应。
File.slice() 切片必须用 file.size 作末尾边界
最后一片漏传是断点续传最常踩的坑，不是网络问题，而是切片逻辑写错了。错误写法 file.slice(start, start + shardSize) 在文件大小不能被分片大小整除时必然越界——比如 10.3MB 文件按 2MB 分片，第 5 片起始位置是 10MB，10 * 1024 * 1024 + 2 * 1024 * 1024 就是 12MB，但实际只有 10.3MB，直接截断导致最后 300KB 永远不上传。
正确做法只有一条：所有切片都用 const end = Math.min(file.size, start + shardSize) 计算终点，或更直白地——最后一片直接用 file.slice(lastStart, file.size)。切片总数必须用 Math.ceil(file.size / shardSize)，用 Math.floor 会少算一片。
文件唯一 ID 必须基于内容计算 MD5，不能拼接 name + size
用户反复保存同名截图、不同设备导出相同尺寸文件、甚至同一文件改名再选一次——这些都会让 fileName + size 冲突。服务端一旦把两个不同文件当成同一个 fileId，后续上传就覆盖或错乱。
前端必须用 spark-md5（或 SubtleCrypto.digest()）对整个文件内容计算哈希，作为 fileId。上传前先发 GET 请求：/upload/status?fileId=xxx，服务端返回已传切片索引数组，比如 {uploadedChunks: [0,1,3]}，前端就跳过这些索引。
立即学习“前端免费学习笔记（深入）”；
localStorage 的 key 也得是这个 fileId，不是 fileName + size。隐私模式下 localStorage 可能抛异常，得包一层 try/catch，降级存到内存对象里。
FormData 每片必须带 chunkIndex、totalChunks、fileId
服务端靠这三者定位临时文件、做幂等写入、校验顺序和完整性。缺任何一个，合并阶段就会失败或错位。
单片 Blob 不宜超过 5MB：2 * 1024 * 1024（2MB）到 5 * 1024 * 1024（5MB）是安全上限。超过 10MB，Chrome 构造 FormData 时可能报 RangeError: Maximum call stack size exceeded，Firefox 也会卡顿；更大的风险是 JS 引擎把整个 Blob 加载进内存，页面假死。
每片上传请求的 URL 后要加随机参数或设 headers: {'Cache-Control': 'no-cache'}，否则 Chrome 可能复用缓存响应，让你误以为切片已成功上传。
切片上传后不能依赖 HTTP 200 就认为落盘成功
HTTP 200 只代表 Nginx 或网关返回了响应，不代表服务端真正把数据写进磁盘。Nginx 可能缓存了成功响应，后端写磁盘失败却没暴露错误——前端重试时发现服务端根本没有那片数据，又得从头来。
所以服务端接口必须在磁盘写入完成后才返回成功状态码，且前端需校验响应体是否含明确确认字段（如 {"status":"success","chunkIndex":3}），不能只看 status code。上传失败的切片要记录索引并重试，重试次数建议设为 3 次，超过则暂停并提示用户手动恢复。
真正难的不是切片或发请求，而是前后端对“已传”的定义是否一致：前端认为上传完成 = 收到 200 + 响应体确认；服务端认为接收完成 = 磁盘落盘 + 索引更新 + 状态持久化。这两边只要有一边松动，断点就变成“伪续传”。
