gumbo_parse()爆内存主因是误用导致资源未释放：将gumbooutput*存入全局缓存或node.js闭包却不调用gumbo_destroy_output()，或解析非html内容触发整数溢出；须在解析前校验content-type和content-length。
超大规模 HTML 文档（如数 MB 以上、万级节点）用常规 DOM 解析必然内存失控；流式解析不是“可选优化”，而是唯一可行路径——但仅换解析器不够，必须同步切断 JS 层的隐性引用链。
为什么 gumbo_parse() 仍会爆内存
gumbo-parser 本身是 C 实现、无 GC 压力，但常见误用会让它成为内存泄漏的放大器：
- 调用
gumbo_parse()后，把返回的GumboOutput*直接塞进全局缓存或闭包里，却不调用gumbo_destroy_output() - 在 Node.js 绑定（如
node-gumbo-parser）中，错误地将解析结果长期持有（例如挂到global.cache），导致整个 DOM 树无法被 V8 GC - 未校验响应类型：
Content-Type是application/pdf却仍传给 gumbo，触发底层string_buffer.c整数溢出，malloc 分配远小于预期，后续读取持续覆盖堆内存
实操建议：解析前必加双校验 —— response.headers.get('content-type')?.includes('text/html') + response.headers.get('content-length') ；若为 chunked 编码，需手动计数，超 1MB 立即中断流。
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
流式处理时如何避免 DOM 节点滞留
即使不用完整 DOM，只要你在解析过程中创建了 JS 对象映射 HTML 节点（比如用 Map 存 node.id → {title, url}），就可能形成 Detached DOM tree。
- 不要在
onopentag或遍历回调中缓存原始节点引用（如element或node），只提取必要字段（node.attributes.href、node.children[0].data）并立即丢弃 - 若需跨标签关联（如
<item></item>下的<title></title>和<link>），用栈记录路径（['rss', 'channel', 'item']），匹配后清空栈，不保留任何节点指针 - 在浏览器端用
Response.body.getReader()流式读取时，禁用innerHTML = chunk操作；改用document.createElement()+textContent构建轻量中间结构
$$('*').length 是比内存 MB 数更准的泄漏信号
DOM 节点数持续增长，是内存泄漏最直接、最低成本的确认方式。它不依赖 GC 时机，也不受堆外内存干扰。
- 打开 DevTools Console，执行
$$('*').length记下基线值（如 8421） - 执行一次完整操作闭环（如加载一个含 5000 条目的列表页 → 滚动到底 → 点返回 → 等待 1s）
- 再执行
$$('*').length，若稳定增加（如每次 +480），说明 Detached 节点未释放 - 此时立刻切到 Memory 面板拍两个 Heap Snapshot，Comparison 视图筛选
HTMLAnchorElement或Text，看 Delta 是否正向线性增长
真正棘手的是那些没出现在 $$ 里的泄漏源：iframe 内文档、Shadow DOM、以及被 Closure → function → element 链锁住的已 detach 节点——它们不会抬高 $$ 计数，但会持续吃内存。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
