非法嵌套会触发每次出现即一次局部DOM重建，不可跳过、不可缓存；如<p><div>hello</div></p>在解析到<div>时立即闭合<p>并插入兄弟节点，该过程发生在Tree Construction阶段初，早于JS执行。
非法嵌套会触发多少次 DOM 重建？
不是“一次解析、一次修正”，而是每次非法结构出现，浏览器就立即执行一次局部树重建——且该过程不可跳过、不可缓存、不依赖 JS 执行时机。比如 <p><div>hello</div></p> 在解析到 <div> 时就会中断当前 <p> 节点构建，闭合它，再新建 <div> 作为兄弟节点插入。这个动作发生在 Tokenizer 后、Tree Construction 阶段初，早于任何脚本运行。
实操中可观察到：同一段 HTML 里每多一个非法嵌套（如 <ol><p>item</p></ol>、<span><div></div></span>），DevTools 的 Elements 面板就会多出 1–3 个意外节点，且 document.querySelectorAll('*').length 显著高于源码标签数。
怎么测出非法嵌套引发的重建开销？
别测“页面加载总时间”，要测 Tree Construction 阶段的 CPU 占用突增点。打开 Chrome DevTools → Performance → 点录制 → 粘贴含非法嵌套的 HTML 片段（如用 document.write 注入），停止后看 Flame Chart 中 Parse HTML 下方是否密集出现 Attach Layout Tree 和 Style 子项——这些就是重建引发的连锁计算。
- 对比基线：把
<p><div>A</div></p>改成合法的<div><p>A</p></div>，重跑，Parse HTML时间通常下降 30%–60% - 用
performance.getEntriesByName('navigation')[0].domContentLoadedEventStart减去fetchStart，差值异常高（>120ms）时，大概率有隐式重建在拖慢 DOM 构建 - 禁用所有 JS，只保留 HTML，若仍卡顿，问题一定出在解析阶段而非执行阶段
哪些非法组合最易被忽略却代价最高？
高频但隐蔽的非法嵌套往往藏在框架输出或 CMS 模板里，它们不报错、不警告，但会让 Tree Construction 多走 2–4 层逻辑分支：
立即学习“前端免费学习笔记（深入）”；
-
<table>内直接写<tr>，没包<tbody>：浏览器自动补匿名<tbody>节点，破坏table-layout: fixed，且每个<tr>都要重新推导列宽 -
<button>里放<div>或<p>：按钮默认是 phrasing content 容器，<div>会被剥离并插到 button 外，导致事件绑定失效、焦点顺序错乱 -
<ul>或<ol>直接子节点不是<li>（比如混入<p>或<span>）：列表序号重置、:nth-child()选择器失准、list-style继承链断裂
为什么 Layers 面板里一堆小合成层说明非法嵌套已发生？
非法嵌套导致浏览器生成大量孤立、无语义、无样式的中间节点（比如自动补的空 <p>、<div>），这些节点没有明确的 stacking context，又常被 CSS 触发 position: relative 或 transform，结果就是渲染引擎被迫为每个碎片化块单独建合成层——Layers 面板里出现十几个宽度
此时右键可疑区域 → Break on → subtree modifications，交互触发后断点若停在父级 wrapper 而非目标元素，说明重排早已扩散，不是样式问题，是结构问题。
真正难处理的不是单个非法标签，而是它引发的 DOM 树“雪崩式修正”：一个<p><div> 可能让后续 5 个兄弟节点的样式继承、布局上下文、事件冒泡路径全部偏移。修复必须从源头下手，不能靠 JS 补救。 
