原生 layui.upload 不支持断点续传，因其底层 XMLHttpRequest/iframe 无状态保持能力，且组件不记录分片、文件 ID 等上下文；必须前后端协同实现：前端生成唯一 fileId、上传前校验已传分片，服务端持久化分片状态并保障幂等性与自动清理。
不能自动续传，必须手动实现断点续传逻辑，核心是服务端记录分片状态 + 前端上传前校验已传分片。
为什么原生 layui.upload 不支持断网续传
Layui 的 upload 模块底层依赖 XMLHttpRequest 或 iframe，两者都无内置断点/恢复能力。断网后请求直接中断，error 回调触发，但组件不保存任何上传上下文（如已传分片、文件唯一 ID、当前 chunkIndex），也没有重试队列或状态持久化机制。
常见误操作包括：只在 error 里调 obj.upload() 重试整文件 → 重复上传全部内容；或期望 timeout 触发后自动从断点开始 → 实际仍是全量重发。
必须用分片上传 + 服务端分片状态管理
断网恢复后的“继续”，本质是跳过已成功上传的分片，只传剩余部分。这要求前后端协同：
- 前端在
choose中为文件生成稳定唯一 ID（如md5(file.name + file.size + file.lastModified)） - 每次上传分片时，携带该
fileId和chunkIndex，服务端存入数据库或 Redis（字段：fileId, chunkIndex, status=success） - 上传前（
before中）先发一次GET /api/upload/chunks?fileId=xxx，获取已成功上传的chunkIndex列表 - 根据返回结果动态计算待传分片范围，例如服务端返回
{"uploaded":[0,1,2,4]}，则前端跳过 0–2 和 4，从 3 开始传（注意：需校验是否连续，缺失即需补传）
断网恢复后如何触发“继续”流程
浏览器无法主动感知网络恢复，所以不能靠监听 online 事件自动续传。正确做法是把“续传”变成显式用户动作：
- 在
error回调中判断错误类型：xhr.status === 0 && xhr.readyState === 0或textStatus === 'timeout'，基本可判定为网络问题 - 弹出提示：“上传中断，检测到网络已恢复，是否继续上传？”并提供「继续」按钮
- 点击后，不调
obj.upload()，而是执行自定义续传函数，该函数：① 查询已传分片；② 构造未传分片的FormData；③ 用$.ajax手动发起请求（绕过 layui 的 upload 流程） - 避免在页面 unload 时尝试保存状态 —— 浏览器可能直接终止 JS 执行，localStorage 写入不可靠
最容易被忽略的服务端细节
断点续传失败，80% 出在服务端没做好幂等性和状态清理：
- 分片上传接口必须支持重复提交同一
fileId+chunkIndex→ 返回成功，不报错、不覆盖、不写冗余数据 - 合并接口（
POST /api/upload/merge）要校验所有分片是否齐全，缺一不可，否则返回明确错误（如{"code":500,"msg":"分片缺失: chunk 3"}），前端据此触发补传 - 长期未完成的上传任务需设 TTL（如 24 小时），超时自动清理临时分片文件，防止磁盘爆满
- 不要依赖客户端传来的
totalChunks做校验 —— 它可能被篡改，服务端应以实际收到的分片数为准
真正的断点续传不是“断了再连上就接着走”，而是“每次上传都是独立事务，靠全局状态决定下一步该传谁”。没有服务端状态支撑的前端重试，只是假续传。
