html解析器本身不递归，超深嵌套不会导致js栈溢出；问题出在后续queryselectorall、深度遍历等js操作或css/无障碍性能劣化，需用ast+正则双校验在ci阶段拦截。
如何用正则+AST双校验拦截超深嵌套HTML
静态 HTML 里出现 <div><div><div>...</div></div></div> 这类结构，不是“写法问题”，而是构建时就该被阻断的隐患。靠人工 review 或肉眼数缩进完全不可靠，必须在 CI 阶段介入。
推荐组合策略：
- 用
htmlparser2或parse5构建 AST，在构建脚本中加深度遍历逻辑：一旦发现node.parentNode链长度 > 12，立即报错并中断构建 - 补充正则兜底（防 AST 解析失败）：
/]*>[^]*>[^]*>/i匹配连续三层未闭合标签，命中即告警 - 服务端模板（如 Nunjucks、EJS）中禁止
{% for %}嵌套超过 2 层；Vue/React 中禁用v-for/map套v-for/map
replaceChildren() 替代 innerHTML 的实操边界
replaceChildren() 不是万能解药，它只在特定条件下比 innerHTML 更安全——前提是你要真正控制返回值，且不依赖字符串拼接。
常见误用：
- 写成
el.replaceChildren(htmlString)→ 报错，replaceChildren()只接受 Node 或 DOMString，但传入字符串不会自动解析，会直接当文本插入 - 仍用
items.map(i => `<div>${i}</div>`).join('')拼接再塞进replaceChildren()→ 白费，等价于又走了一次innerHTML路径 - 在 IE 或旧 WebView 环境下无降级 → 必须前置检测：
if ('replaceChildren' in Element.prototype)，否则 fallback 到while (el.firstChild) el.removeChild(el.firstChild)
正确姿势是：每个子节点都用 document.createElement() 显式创建，再统一传入 —— 这样旧节点引用才能被浏览器同步切断。
深层DOM中 parentNode 链断裂导致 Detached 节点驻留
删掉一个 <div> 并不等于释放内存。只要 JS 里还存着对它的引用（哪怕只是缓存了某个深层 <code><span></span>），整条 parentNode 链都会卡在内存里，包括那些早已从 DOM 树移除的祖先节点。
高频泄漏场景：
- 组件卸载后，闭包仍持有
ref.current或document.querySelector('.deep-item')返回的节点 - 用
Map缓存节点映射：nodeCache.set(node, data)，但没在节点移除时nodeCache.delete(node) - 监听器回调里直接访问
e.target.parentElement.parentElement.parentElement，且该回调被长期持有（如挂到window）
验证方式很简单：DevTools Console 执行 $$('*').length，操作前后对比。若稳定增长，立刻拍 Heap Snapshot，筛选 Detached DOM tree，看 Retainers 是否含 Closure。
流式解析大HTML时如何避免节点指针滞留
即使不用完整 DOM，只要你在解析过程中保留了任何原始节点引用（比如 element 或 node 对象），就可能形成 Detached DOM tree —— 尤其在 Node.js 后端用 gumbo-parser 或前端用 Response.body.getReader() 流式读取时。
关键原则：只提取字段，不保留指针。
- 在
onopentag回调里，只取node.attributes.id、node.children[0].data这类基础值，拿到就丢弃node - 需要跨标签关联？用栈记录路径数组（如
['rss', 'channel', 'item']），匹配成功后清空栈，绝不缓存node实例 - 禁用
innerHTML = chunk操作 —— 它会强制浏览器重建整个子树，中间节点极易变成 detached
最隐蔽的坑是：你以为自己没存节点，但第三方库（比如 resize-observer-polyfill）内部悄悄持有了你传进去的 el。所以，凡涉及 DOM 引用的 API，先查文档是否要求显式 unobserve() 或 disconnect()。
