非标准嵌套不会报错但导致dom解析不一致：浏览器解析时遇会立即隐式闭合，生成；而ssr直接输出，hydration时节点树不匹配，触发react/vue hydration失败。
非标准嵌套不会报错，但会导致 DOM 结构在不同环境（服务端渲染、客户端 hydration、不同浏览器）中解析不一致——这不是“看起来差不多”，而是真实节点树被浏览器强制重排，后续 JS 操作和 CSS 选择器都可能失效。
为什么 <p></p><div></div> 在 Chrome 里结构对，但在 React hydrate 时出问题
浏览器解析时，<p></p> 遇到 <code><div> 会立刻隐式闭合自己，生成 <code><p></p>
<div></div>；但服务端模板（如 SSR）若直接输出该字符串，React hydrate 时对比 DOM 树会发现首节点是 <code><p></p>，而预期是 <code><p></p>
<div></div>，从而放弃 hydration 或触发全量重绘。
<ul>
<li><code><p></p> 是格式化元素，规范禁止它包含块级标签，所有主流解析器（Chrome/Firefox/Safari/IE）都按同一规则处理：先闭合 <code><p></p>，再开 <code><div></div>
v-html、React 的 <code>dangerouslySetInnerHTML 同样走原生解析流程，框架不干预容错逻辑
如何用 DevTools 快速定位非法嵌套位置
靠肉眼扫 HTML 几乎无效，真正有效的是观察浏览器实际构建的 DOM 树：
- 在 Chrome Elements 面板右键任意节点 → “Edit as HTML”，随便改一个字符再回车：如果节点层级突然跳变（比如某个
<div> 被移到外面），说明原始嵌套不合法 <li>运行 <code>document.querySelectorAll('*').forEach(el => { if (!el.parentElement) console.log('孤立元素:', el) })，输出的节点就是被浏览器“踢出来”的非法子元素</code> </li> <li>VSC 安装 <code>HTMLHint</code> 插件，并启用 <code>attr-validate</code> 和 <code>doctype-first</code> 规则，保存时实时标红（例如 <code><ul><div></div></ul></code> 会被标记为错误）</li> <h3><pre class="brush:php;toolbar:false;">
漏<tbody> 为什么有时正常、有时错位 <p>浏览器必须补 <code><tbody>，但补的位置固定在 <code><table> 下第一层；一旦你混入 <code><thead> 或 <code><tfoot>，顺序就决定补的位置是否符合预期： <ul> <li><code><table><tr><td></td></tr></table> → 补为 <code><table><tbody><tr><td></td></tr></tbody></table> -
<table> <thead><tr><th></th></tr></thead> <tr><td></td></tr> </table>→ 第二个<tr> 会被塞进自动生成的 <code><tbody>，哪怕你没写，且 <code><tbody> 必定在 <code><thead> 之后 <li>Firefox 和 Safari 对 <code><colgroup> 处理更严格，漏写或位置错会导致整列样式丢失；Chrome 则可能容忍但布局偏移</colgroup>
最隐蔽的问题不是标签没闭合，而是闭合顺序和父/子关系违反了 HTML Living Standard 的内容模型——比如把 <button> 放进 <code><a>，或者用 <code><span> 包 <code><h2>。这些错误在开发机上看不出异样，一上生产环境，尤其配合 SSR 或 SEO 抓取，DOM 就会分裂成两套结构。</h2>
