加载超大XML时应避免XMLHttpRequest全量读取，改用流式解析（如XMLParser+ReadableStream）或服务端分页；DOMParser会阻塞主线程并导致内存溢出。
XML 文件太大，浏览器直接加载会卡死？别用 XMLHttpRequest 全量读取
浏览器加载超大 XML（比如几百 MB）时，XMLHttpRequest 或 fetch 会等整个响应体下载并解析完才触发 load 或 then，期间页面无响应，内存飙升，甚至崩溃。这不是网络慢的问题，而是 DOM 解析模型的硬限制——XML 必须完整载入才能构建树结构。
真正可行的路只有一条：放弃 DOM 解析，改用流式解析（SAX/Streaming），边读边处理，不保留全文。
- 浏览器原生不支持 SAX，但可用
XMLParser配合ReadableStream实现分块解析 - 服务端若可控，优先改用 JSON Line-delimited（NDJSON）或分页 API，比“大 XML”更合理
- 若必须用 XML 且无法改服务端，客户端唯一能做的就是「按字节切片 + 手动定位标签边界」，但极易出错，不推荐
用 XMLParser + TextDecoderStream 流式解析 XML 片段
HTML5 标准中 XMLParser 本身不支持流，但可以配合 ReadableStream 的 pipeThrough 链，在数据到达时逐段喂给解析器。关键在于：不能等整个文件，而要监听 parser.onerror 和 parser.onelement 等回调，只提取你需要的节点。
以下示例假设 XML 是扁平列表结构（如大量 <item>），目标是提取每个 <item id="..."> 的属性并忽略其余内容：
立即学习“前端免费学习笔记（深入）”；
const response = await fetch('/huge.xml');
const reader = response.body.getReader();
const parser = new XMLParser({
ignoreAttributes: false,
ignoreDeclaration: true,
ignorePiTags: true,
stopNodes: ['item'] // 只触发 item 开始/结束事件
});
// 自定义流处理器：每次收到 chunk 就 push 给 parser
async function streamToParser(reader, parser) {
while (true) {
const { done, value } = await reader.read();
if (done) break;
const text = new TextDecoder().decode(value);
parser.parse(text); // 注意：不是 parseAsync，这里必须同步喂入
}
}
parser.onElement = (el) => {
if (el.name === 'item' && el.isSelfClosing === false) {
console.log('found item:', el.attributes?.id);
}
};
await streamToParser(reader, parser);
⚠️ 注意：XMLParser（来自 fast-xml-parser）默认不支持流式，上面代码基于其 v4+ 的实验性流模式；若用原生 DOMParser，它根本不接受部分字符串——会直接报 "Invalid XML" 错误。
Miller (mlr) 是一个命令行工具，用于查询、整形和重新格式化名称索引数据，如 CSV、TSV、JSON 和 JSON Lines。它将 awk、sed、cut、join 和 sort 的功能整合到一个专为结构化数据处理而构建的单一工具中。
服务端分块返回 XML，客户端按需请求 <item> 子集
最稳定、兼容性最好的方案，是让后端支持范围查询，例如：
-
GET /api/items?offset=0&limit=1000→ 返回仅含 1000 个<item>的小 XML - 前端用
IntersectionObserver触发懒加载，或滚动到底部再拉下一页 - 避免一次性请求 50MB XML，把压力从浏览器转移到服务端分页逻辑
如果后端是 Java/Spring，可用 StAX（XMLStreamReader）快速跳过前 N 条；如果是 Python，用 xml.etree.ElementTree.iterparse 配合 start 事件过滤，性能远高于 parse。
为什么不用 DOMParser + response.text()？
因为 response.text() 必须等全部响应完成才 resolve，期间 JS 主线程阻塞，浏览器冻结。即使你接着用 new DOMParser().parseFromString(...)，也改变不了「先载入全部文本」这个前提。实测加载 200MB XML 会触发 RangeError: Maximum call stack size exceeded 或直接 OOM。
真正能绕开这个问题的只有两条路径：
- 服务端切片（推荐，可控、稳定、可缓存）
- 客户端流式 SAX 替代方案（如
fast-xml-parser的stream模式，或 Web Worker 中用iterparse类库隔离主线程）
任何试图“手动 split XML 字符串再分别 parse”的做法，都会在标签跨 chunk 边界时失败——比如 <item id="123"> 被切成两半，就永远无法正确闭合。
