用 DOMParser 而不是正则处理 HTML，因 HTML 是上下文敏感语言，正则无法识别嵌套层级和作用域，而 DOMParser 可自动修复语法错误；压平无效嵌套需定位冗余包裹层并合并或替换为语义化标签，再通过 DevTools 检查渲染树深度与 Layout 耗时验证效果。
为什么用 DOMParser 而不是正则处理 HTML
正则匹配 <div> 或 </div> 看似简单，但一碰到 <script>console.log('</div>');</script> 或 <pre><div></div></pre> 就直接崩——HTML 是上下文敏感语言，正则无法识别标签嵌套层级和作用域。DOMParser 由浏览器原生实现，自动修复缺失闭合、错位嵌套、属性引号不匹配等问题，这才是真正“零风险”的起点。
如何用 DOM 遍历识别并压平无效嵌套
关键不是删标签，而是定位那些纯为样式或对齐而存在的冗余包裹层。真实 DOM 树中，深度 >6 的节点几乎都来自这类结构：
-
<div class="card"><div class="card-body"><div class="card-content"><p>...</p></div></div></div>→ 合并为<article class="card"><p>...</p></article>，用 CSS 控制内边距与圆角 -
<div><div><input type="text"></div></div></div>→ 改用<label class="input-group"><input type="text"></label>，语义+扁平双得 - SSR 模板生成的空 wrapper：
<div class="page"><div class="main"><div class="container">...→ 检查 class 是否真被 CSS 引用，未使用的整层删除
压平后怎么验证是否生效
别只看源码缩进，要测真实渲染树深度：
- Chrome DevTools → Elements 面板，右键任意节点 → Show DOM properties，查看
depth值；超过 6 就必须干预 - Performance 面板录制首屏加载，重点关注
Layout阶段耗时：深度每降 1 层，该阶段通常下降 15–30%，尤其在低端 Android 设备上更明显 - 运行
document.querySelector('.a .b .c .d')类选择器，若匹配慢或失败，大概率是父链过长导致回溯成本飙升，不是选择器本身问题
容易被忽略的“隐形深度”来源
某些框架（如 Next.js、Nuxt SSR）会在服务端注入不可见 wrapper，比如 <div data-nextjs-root> 或 <div id="__next"> 下挂载的多层 <div>。它们虽不渲染，但仍参与样式继承、getComputedStyle 计算和 layout 触发。必须连同可见 DOM 一起审查——用 document.querySelectorAll('div').length 对比 document.body.children.length，差值过大就说明存在大量无意义中间层。
立即学习“前端免费学习笔记（深入）”；
