XML文件上传进度监听依赖XMLHttpRequest.upload.onprogress事件，与文件类型无关；fetch不支持上传进度，需用XMLHttpRequest配合FormData；实时速率应通过滑动窗口法计算。
XML 文件上传时如何监听进度
XML 文件本身没有特殊上传逻辑，浏览器对它的处理和普通文件完全一致。真正起作用的是 XMLHttpRequest 或 fetch 的上传事件机制，关键在监听 upload.onprogress，而不是文件类型。
常见错误是以为要解析 XML 内容才能获取进度——其实进度发生在二进制传输阶段，和文件内容格式无关。只要后端接收的是原始字节流（比如用 multipart/form-data），前端就能拿到真实上传速率。
- 必须用
XMLHttpRequest（fetch目前不支持上传进度事件） - 请求必须是
POST且带FormData，不能直接传字符串或 JSON -
XMLHttpRequest.upload对象才有onprogress，XMLHttpRequest实例本身没有
为什么用 XMLHttpRequest 而不是 fetch
fetch 没有暴露上传过程的底层流控制，它只提供响应体的读取能力（response.body.getReader()），无法得知「已发多少字节」。而 XMLHttpRequest.upload.onprogress 会持续触发，附带 loaded 和 total 字段，可直接算出瞬时速率。
典型错误现象：fetch 发送大 XML 文件时，页面卡顿、进度条不动、直到最后才跳到 100%——这不是 bug，是设计限制。
立即学习“前端免费学习笔记（深入）”；
- 如果硬要用
fetch，只能靠服务端返回分块确认（如 WebSocket 推送进度），但增加后端复杂度 -
XMLHttpRequest兼容性好，连 IE10 都支持upload.onprogress - 注意：不要在
XMLHttpRequest上设timeout过短，大 XML 上传慢容易误判失败
计算实时上传速率的正确方式
仅靠单次 onprogress 的 loaded/total 只能得百分比，要算速率必须记录时间戳做差值。不能简单用 (loaded - lastLoaded) / (now - lastTime)，因为事件触发不均匀，尤其网络波动时。
推荐用滑动窗口法：缓存最近 3–5 次事件的时间与字节数，用首尾差值算平均速率，避免毛刺干扰。
let progressHistory = [];
xhr.upload.onprogress = (e) => {
const now = Date.now();
progressHistory.push({ time: now, loaded: e.loaded });
if (progressHistory.length > 5) progressHistory.shift();
const first = progressHistory[0];
const last = progressHistory[progressHistory.length - 1];
if (last.time > first.time) {
const rate = Math.round((last.loaded - first.loaded) / (last.time - first.time) * 1000); // bytes/sec
console.log(`<code>${rate}</code> B/s`);
}
};XML 文件名或编码是否影响进度监听
不影响。浏览器上传时只管二进制流长度，不管文件扩展名是不是 .xml，也不管内容里有没有 <?xml version="1.0"?>。唯一会影响的是后端能否正确解析——但那是另一层问题。
容易被忽略的坑：如果前端把 XML 字符串转成 Blob 再上传，却没指定 type: "text/xml"，部分旧安卓 WebView 可能错误识别 MIME 类型，导致后端拒绝接收；但这不会让进度条失效，只是上传可能被中断。
- 构造
Blob时务必写明类型：new Blob([xmlString], { type: "text/xml" }) - 如果 XML 含中文，确保字符串编码为 UTF-8（JS 字符串默认就是），不要手动调用
encodeURI等破坏二进制结构 - 服务端返回 413（Payload Too Large）时，前端进度条可能卡在 99%，实际是服务端提前切断连接——需监听
onerror和状态码判断
XML 文件上传进度条的关键不在“XML”，而在上传通道是否暴露了底层字节流信息。真正容易被绕晕的地方，是把内容解析逻辑和传输监控混在一起想。
