分片上传通过并发上传、失败重试和资源控制提升整体稳定性与平均完成速度，推荐分片大小2MB–5MB，配合并发数3–6、断点续传及进度反馈优化体验。
分片切片本身不直接“提升速度”，而是通过并发上传、失败重试和资源控制，让整体上传更稳定、更可控，从而在真实网络环境下显著缩短平均完成时间。关键不在单次更快，而在减少重传、压满带宽、避开超时。
合理设置分片大小
分片太小（如 256KB）会导致 HTTP 请求过多，头部开销大、服务端压力高；太大（如 20MB）则单次上传耗时长、易超时、失败后重传成本高。推荐区间是 2MB–5MB，兼顾网络波动容忍度与请求效率。视频类文件可倾向 4–5MB，文档或压缩包可设为 2–3MB。实际中可结合用户网络类型（如检测 navigator.onLine 或用 Navigator API 粗略判断）动态调整。
并发上传多个分片
浏览器默认对同一域名有连接数限制（通常 6 个），但上传大文件时只用 1 个连接明显浪费带宽。应主动控制并发数（例如 3–6 个），避免打满导致阻塞或服务端限流：
- 用 PromisePool 或手写队列管理并发，比如每次最多启动 4 个 fetch 请求
- 每个请求携带 index、total、fileHash、filename 等元信息，方便服务端识别顺序与归属
- 失败分片自动加入重试队列（建议最多重试 2–3 次，带指数退避）
跳过已传分片，实现断点续传
页面刷新或网络中断后，无需从头开始。核心是上传前先查服务端：
立即学习“Java免费学习笔记（深入）”；
- 前端计算文件唯一标识（推荐 SparkMD5 分块计算 + 全量校验，或 Web Crypto API 的 SHA-256）
- 请求
/upload/verify?fileHash=xxx获取已成功上传的分片索引列表 - 本地跳过这些 index，只上传剩余分片
- 状态可临时存 localStorage（轻量）或 IndexedDB（支持更大元数据）
配合进度反馈与体验优化
用户感知的“快”，不只是完成时间短，更是过程透明、可预期：
- 用
XMLHttpRequest.upload.onprogress或fetch+ReadableStream（较新方案）获取单个分片上传进度 - 整体进度 = 已完成分片数 × 平均分片大小 + 当前分片已传字节数，再除以总大小
- 上传完成前，禁用重复提交按钮；合并阶段显示“正在合成文件…”而非“上传中”
