进度条需JavaScript计算并更新，因<progress>仅被动显示；须用XMLHttpRequest监听单个分片upload.onprogress，按权重加权计算全局进度；需维护分片状态表防重复/乱序，并以后端确认落盘为准。
大文件分片上传的进度条不是靠 HTML 自身能实现的——<progress> 标签只能被动显示数值，真正的进度计算和更新必须由 JavaScript 控制，且依赖后端配合返回分片状态或接收响应。
为什么 <progress> 不能直接绑定分片上传？
因为浏览器原生的 <progress> 是纯 UI 元素，它不感知网络请求、不监听 XMLHttpRequest.upload.onprogress、也不理解“第 3 片已发、第 5 片失败”这类业务状态。你给它设 value="60"，它就显示 60%，但这个 60% 是你算出来的，不是它自动感知的。
常见错误现象：
– 把 <progress> 放在页面里就以为“有了进度条”
– 用 fetch() 上传但没监听 upload.onprogress，导致始终卡在 0%
– 分片并发上传时，简单累加每个分片的 loaded/total，结果进度跳变甚至超过 100%
如何用 XMLHttpRequest 监听单个分片上传进度
只有 XMLHttpRequest 支持细粒度的上传事件监听；fetch 目前不支持上传进度（ReadableStream 方案太重，不适用于普通分片场景）。
立即学习“前端免费学习笔记（深入）”；
实操要点：
- 每个分片必须创建独立的
XMLHttpRequest实例，不能复用 - 必须在
open()之后、send()之前绑定upload.onprogress -
event.loaded是当前分片已上传字节数，event.total是该分片大小（注意：不是整个文件） - 避免直接用
event.loaded / event.total更新全局进度——要按分片权重加权计算
示例关键片段：
const xhr = new XMLHttpRequest();
xhr.upload.onprogress = (e) => {
const chunkProgress = e.loaded / e.total;
// 当前分片占总文件的比例
const weight = chunk.size / totalSize;
const globalProgress = currentDoneRatio + chunkProgress * weight;
progressEl.value = Math.min(100, globalProgress * 100);
};怎么合并多个分片的完成状态并防重复/乱序
前端需要维护一个分片状态表，不能只靠“发完就算成功”。后端返回的响应可能延迟、失败或乱序到达。
推荐做法：
- 用
Map存储chunkIndex → { status: 'pending'|'success'|'error', loaded: number } - 每次
xhr.onload后校验 HTTP 状态码和响应体（例如后端返回{ ok: true, chunkIndex: 4 }） - 只在所有分片都标记为
'success'后，才触发“合并请求” - 对同一分片的重复响应做幂等处理（比如检查
chunkIndex是否已为'success'）
容易踩的坑：
– 没做状态去重，导致“第2片成功”来两次，currentDoneRatio 被多加一次
– 后端未返回 chunkIndex，前端靠请求顺序推断，一出错就全偏移
– 并发数设太高（如 10），触发浏览器连接限制，部分请求被挂起，进度停滞
服务端返回分片状态时，前端如何同步刷新进度条
如果业务要求“上传完立刻查状态”，就得轮询或用 WebSocket。但更轻量的做法是：上传每个分片后，立即发起一个轻量 GET /api/chunk-status?fileId=xxx&chunkIndex=7 请求，确认落盘结果。
这时进度更新逻辑变为：
- 分片上传成功 → 状态表设为
'uploading'→ 发起状态查询 - 状态查询返回
{ status: 'saved' }→ 设为'success'→ 重新计算已完成比例 - 若返回
{ status: 'missing' }或超时 → 设为'error'，允许重试
注意：XMLHttpRequest 的 onload 只代表请求发出去且收到响应，不代表服务端真正写入磁盘。真实进度必须以后端确认为准。
复杂点往往不在前端怎么画条，而在于怎么定义“这一片到底算不算传完了”——是 TCP ACK？是 HTTP 200？还是后端 fsync 完成？这个边界一旦模糊，进度条就会变成心理安慰。
