XML DOM解析在移动端卡顿的根本原因是浏览器构建完整DOM树时触发样式计算、布局预备等隐式操作，而移动端JS引擎和内存带宽较弱；应改用fast-xml-parser等流式解析器、服务端gzip压缩+客户端Web Worker解压、indexedDB缓存带ETag验证的结果。
XML DOM 解析在移动端卡顿的根本原因
HTML5 移动端用 DOMParser 解析中大型 XML（比如 >500KB 或含上千节点）时卡顿，不是因为“XML 过时”，而是浏览器在内存中构建完整 DOM 树的开销太大：每个 Element、Text、Attr 节点都会触发样式计算、布局预备、事件系统挂载等隐式操作，而移动端 JS 引擎和内存带宽远弱于桌面端。
用 SAX 风格流式解析替代 DOMParser
现代浏览器不原生支持 SAX，但可用 XMLHttpRequest + responseType = 'document' 配合分块读取模拟流式行为；更推荐的是使用轻量级纯 JS SAX 解析器，如 sax-js 或 fast-xml-parser（注意选 ignoreAttributes: true、ignoreDeclaration: true 等降开销选项）。
关键点：
- 避免
new DOMParser().parseFromString(xmlStr, 'text/xml')—— 字符串转 DOM 是最大瓶颈 - 改用
fastXmlParser.parse(xmlStr, { ignoreAttributes: true, ignoreNameSpace: true, allowBooleanAttributes: true }) - 若 XML 有固定结构，可进一步跳过不需要的节点路径，用
onTagOpen/onText回调只提取目标字段
预处理 XML：服务端压缩 + 客户端解压
XML 文本冗余高，未压缩时体积常是等效 JSON 的 2–3 倍。移动端解析耗时与字符串长度强相关。直接传输 gzip 后的 XML 并不可行（fetch 默认不自动解压二进制响应），需显式处理：
fetch('/data.xml.gz')
.then(res => res.arrayBuffer())
.then(buffer => pako.inflate(new Uint8Array(buffer)))
.then(uint8 => new TextDecoder().decode(uint8))
.then(xmlStr => fastXmlParser.parse(xmlStr, options))
注意：
- 服务端必须返回
Content-Encoding: gzip，且fetch请求头不设Accept-Encoding（否则部分 Android WebView 不走解压流程） -
pako的inflate是同步阻塞的，建议用Web Worker包裹，防止主线程冻结 - gzip 后仍 >1MB 的 XML，应考虑服务端改用 Protocol Buffers 或 CBOR 序列化，前端再转换为轻量 JS 对象
缓存解析结果并标记版本
XML 内容不变时反复解析毫无意义。但不能只靠 localStorage 存整个对象（序列化开销大、无类型、易爆容量），推荐：
- 用
indexedDB存解析后的 JS 对象，键为xmlUrl + '?v=' + etag - HTTP 响应头带
ETag或Last-Modified，请求前先发HEAD判定是否变更 - 避免用
JSON.stringify()存原始 DOM 结构 —— 会丢失函数、循环引用、Date等类型，且体积膨胀
真正卡顿的从来不是“怎么写解析代码”，而是没意识到 XML 在移动端本质是「不适合直接解析的传输格式」——能转成 JSON 就转，能分片就分片，能服务端裁剪就别传全量。
