DOMParser.parseFromString() 解析大文件会崩，因需将整个 HTML 字符串载入内存（25MB 文件膨胀至约1.3GB），触发V8 OOM或主线程冻结，且不支持流式输入、无法中断解析。
直接用 innerHTML 或 DOMParser.parseFromString() 解析几十 MB 的 HTML 文件，基本等于主动卡死浏览器——这不是性能问题，是内存和主线程调度失控。
为什么 DOMParser.parseFromString() 在大文件上会崩
DOMParser.parseFromString() 要求输入字符串，意味着你必须先用 FileReader.readAsText() 或 response.text() 把整个 HTML 加载进内存。对一个 25MB 的 UTF-8 文件，JS 字符串在内存中会膨胀到约 1.3GB（UTF-8 单字节 → JS 字符双字节 + 内存对齐开销），V8 直接触发 GC 压力或 OOM。Chrome 会无响应超 6 秒，且无法中断解析过程。
常见错误现象：DOMParser.parseFromString(htmlStr, 'text/html') 在 15MB+ HTML 上卡住、DevTools Memory 面板显示堆内存陡升、控制台无报错但页面冻结。
- 它不支持流式输入，必须等完整字符串就绪才开始解析
- 生成的 DOM 树全部驻留主线程，哪怕你只想要
<a href>列表 - 无法指定编码 fallback；若 HTML 声明
<meta charset="gbk">但你传入 utf-8 字符串，解析结果乱码且不可逆
用 htmlparser2.WritableStream + Worker 实现可控流式解析
核心思路：把二进制切片移交 Worker，在后台线程解码 + 增量解析，主线程只做路由和轻量提取。
立即学习“前端免费学习笔记（深入）”；
关键步骤：
- 主线程用
FileReader.readAsArrayBuffer()或Response.body.getReader()获取Uint8Array，避免字符串化 - 读取前 1024 字节，用
TextDecoder尝试utf-8/gbk/iso-8859-1，提取<meta charset="...">（正则即可：/<meta[^>]+charset\s*=\s*["']([^"']+)/i） - 每累积约 64KB
Uint8Array，用postMessage({ chunk, encoding }, [chunk.buffer])发给 Worker（注意 transferable） - Worker 内：用
new TextDecoder(encoding).decode(chunk)得字符串，喂给htmlparser2.WritableStream，在onopentag/ontext回调里只取你需要的字段（如attrs.href、text.trim()），立刻丢弃 node 引用
示例 Worker 片段：
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
const parser = new htmlparser2.WritableStream({
onopentag: (name, attrs) => {
if (name === 'a' && attrs.href) results.push(attrs.href);
},
ontext: (text) => {
if (text.trim().length > 50) results.push(text.trim().slice(0, 50) + '…');
}
});
// 每次 feed 后记得 parser.resume()，并显式 parser.destroy() 防泄漏
PyQuery / BeautifulSoup 在 Python 侧如何避免内存爆炸
Python 侧同样不能直接 BeautifulSoup(html_str, 'lxml') —— 20MB 字符串在 CPython 中仍会吃掉 300MB+ RSS 内存，且 lxml 构建完整树后 GC 不及时。
实操建议：
- 用
lxml.etree.iterparse()替代etree.parse()：边读边解析，遇目标标签（如div[@class="item"]）立即处理并root.clear() - PyQuery 初始化时加
parser='html'（而非默认'xml'），否则对残缺 HTML 会抛LxmlError - 大量文件批量处理时，用
multiprocessing.Pool而非threading，绕过 GIL 对 CPU-bound 解析的限制 - 禁用 lxml 的 DTD 和 XInclude 加载：
etree.XMLParser(load_dtd=False, no_network=True, resolve_entities=False)
易踩坑点：PyQuery 的 html() 方法默认返回子节点拼接字符串，若节点含 script/style，可能意外执行或污染内容；提取纯文本请坚持用 text()。
什么时候该放弃流式解析，改用服务端预处理
当 HTML 含大量内联 JS/CSS、动态 document.write()、或依赖运行时 DOM 操作（如 Vue SSR 注水）时，客户端流式解析必然失效——你不是在解析 HTML，是在模拟浏览器引擎。
此时应放弃前端解析，改为：
- 服务端用 Puppeteer/Playwright 渲染成静态 HTML（带
data-*标记），再传输 - 用
html2text提前转为结构化 Markdown，前端只做轻量渲染 - 对爬虫中转场景，直接用
curl -N流式拉取，管道进grep -oP '<a href="\K[^"]*'这类命令行工具，比 JS 快一个数量级
最常被忽略的一点：流式解析的“快”，只体现在首屏数据抵达时间；但如果你要提取的是页面底部的 <footer> 里的版权年份，那它和等完整响应没区别——解析位置决定一切，别迷信“流式”二字。
