XMLHttpRequest Level 2 的 upload 属性必须显式访问，上传进度事件仅在 xhr.upload 上触发，需用 xhr.upload.addEventListener('progress', handler)；分片上传需按 chunkSize 切片、带唯一标识、缓存成功分片状态、HEAD 校验续传，并用加权平均计算整体进度。
XMLHttpRequest Level 2 的 upload 属性必须显式访问
很多人卡在进度条没反应，根本原因是直接监听 XMLHttpRequest 实例本身，而没意识到上传进度事件只在 xhr.upload 对象上触发。Level 2 明确把下载（xhr）和上传（xhr.upload）事件分离了。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 必须用
xhr.upload.addEventListener('progress', handler)，写成xhr.addEventListener('progress', ...)完全无效 - 如果服务端返回 200 但进度始终为 0，先检查是否漏了
Content-Length响应头——部分代理或 CDN 会剥离它，导致浏览器无法计算总大小 -
event.lengthComputable为false时，event.total是 0，此时只能靠服务端回传的分片序号或自增计数器模拟“伪进度”
分片上传需手动控制 Blob.slice() 而非读取整个文件
HTML 编辑器里拖入大文件（比如 100MB 的 HTML 模板包），不能用 FileReader.readAsArrayBuffer(file) 一次性加载——内存爆炸且阻塞 UI。正确做法是按固定 chunkSize 切片，逐片发请求。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 推荐 chunkSize 设为
5 * 1024 * 1024（5MB），太小增加 HTTP 开销，太大影响暂停/续传粒度 - 切片用
file.slice(start, end)，注意第二个参数是end（不包含），不是长度；别写成file.slice(start, start + chunkSize)然后忘记边界判断 - 每片请求必须带唯一标识：建议用
filename+chunkIndex+totalChunks组合成请求头，例如X-Upload-Chunk: 3/20，服务端靠这个做校验和合并
HTML 编辑器中处理暂停/续传的关键是维护 abort() 和状态缓存
用户编辑 HTML 时突然点暂停，不是简单调 xhr.abort() 就完事——得记下已成功上传的分片索引，否则续传时重复发或跳片都会导致服务端合并失败。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 每次分片上传成功后，把
{index: 5, etag: "abc123"}存进localStorage或内存 Map，不要只依赖服务端返回的“已存在”响应 - 调
xhr.abort()后必须重置xhr实例，不能复用同一个对象发下一片——否则可能触发NetworkError或状态混乱 - 续传前先发个 HEAD 请求查服务端已存分片列表（如
/upload/status?file_id=xxx），比纯客户端缓存更可靠；但注意跨域要配好Access-Control-Expose-Headers
进度条渲染别直接用 event.loaded / event.total 做百分比
分片上传的“整体进度”不是线性叠加的。比如第 1 片 5MB 传了 90%，第 2 片刚发起还没数据，这时算全局进度会突降——用户看到进度条来回跳，体验极差。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 用加权平均：整体进度 =
(已成功分片数 × chunkSize + 当前片已传 bytes) / totalSize，其中totalSize来自file.size，不是所有event.total的和 - 避免高频重绘：用
requestAnimationFrame节流进度更新，而不是每个progress事件都更新 DOM - 上传完成前，最后 1% 最容易卡住——通常是服务端合并耗时，这时可显示“正在处理，请稍候…”而非死等进度到 100%
分片序号、ETag 校验、服务端幂等合并逻辑，这三块任何一个出错，前端进度再准也没用。别只盯着 XMLHttpRequest 的 API 表面行为。
