文件上传重试需分片上传、状态持久化与服务端协同，核心是只重传失败分片而非整文件；须校验唯一标识、内容哈希并支持幂等接收，配合指数退避重试与用户可见反馈。
带文件上传的请求重试不能简单套用普通 API 请求的重试逻辑——文件体积大、上传耗时长、中断后重复发送成本高，必须结合分片、状态持久化与服务端协同才能真正可靠。核心不是“重发整个请求”，而是“只重传失败部分，并跳过已成功内容”。
必须分片上传，避免整文件重试
大文件（>2MB）直接用 FormData 上传，一旦失败就得从头再来，既浪费带宽又伤害体验。正确做法是主动切片：
- 用 File.slice() 按固定大小（推荐 2–5MB）切割文件，生成分片数组
- 每个分片携带唯一标识：建议组合 文件 hash + 分片序号 + 总片数，避免同名文件覆盖或错片
- 不依赖单次 fetch 调用，而是为每个分片单独发起上传请求，失败只影响当前片
上传前查状态，失败后只重试缺失分片
页面刷新或网络中断后，前端需知道“哪些片已存、哪些还没传”。这需要前后端配合：
- 上传开始前，先发 GET 请求（如 /upload/status?uploadId=xxx）向服务端查询已成功接收的分片索引列表
- 前端比对后，仅对 未返回或标记为 failed 的分片发起上传；已成功的直接跳过
- 上传失败的分片，记录其 index 到内存或 localStorage（如 { uploadId: 'abc123', failedChunks: [2, 5] }），下次恢复时精准重试
服务端必须支持幂等接收与完整性校验
前端再小心，也依赖服务端不把同一分片当新内容写两次。关键要求：
立即学习“Java免费学习笔记（深入）”；
- 接收分片时，服务端需校验：文件唯一标识（如 SHA-256）+ 分片序号 + 分片内容哈希，三者一致即直接返回 success，不落盘
- 合并前强制验证所有分片是否齐全、每片哈希是否匹配，防止中间篡改或丢片
- 为每个上传会话设置超时（如 24 小时），自动清理临时分片，避免磁盘堆积
重试策略要更克制，且带用户感知
文件上传耗时久，用户等待耐心更低，重试不能盲目：
- 单个分片最多重试 2～3 次，间隔采用指数退避（如 1s → 3s → 9s）+ 抖动（±300ms），防重试风暴
- 使用 AbortController 控制单次分片上传超时（如 30 秒），超时即标记为 failed，不卡死后续流程
- UI 层需明确反馈：进度条持续显示、失败分片高亮、提供“重试失败片”按钮，而非静默重试
不复杂但容易忽略：没有服务端状态校验的“断点续传”只是假象；没做分片的“重试”本质是用户体验倒退。
