浏览器解析时遇到<div>会立即闭合<p>，因<p>是短语级容器，只允许phrasing content（如<span>、<em>、<img>），<div>属flow content，触发解析器自动插入</p>并移出<div>；同理<ul>内放<div>会被移为兄弟节点，<table>漏<tbody>则浏览器强制补全但位置不可控，导致DOM结构、CSS选择器、JS查询及SSR hydration异常。
浏览器解析时
遇到
会立刻闭合
虽然
标签在HTML解析器眼里是“短语级容器”，只接受 phrasing content（如<span>、<em>、<img>）。一旦扫描到<div>这种 flow content，解析器不会报错，也不会继续嵌套，而是**立即插入一个隐式的</p>**，再把<div>放到刚闭合的<p>外面。
常见现象包括：
-
<p>文字<div>区块</div></p>实际生成的 DOM 是：<p>文字</p><div>区块</div> - 原本想用
p > div选中元素，结果返回null -
<p>的 margin-bottom 消失，视觉上段落和区块之间“没空隙”
<ul>里放<div>会导致列表结构被撕开
<ul> 和 <ol> 的合法子元素只有 <li>。任何其他标签（<p>、<div>、<h3>）或空白文本未包裹在 <li> 内，都会触发解析器强制修正：把非法节点移出列表，作为兄弟节点插入。
例如：
-
<ul><div class="item">A</div></ul>→ 实际 DOM 变成：<ul></ul><div class="item">A</div> -
<ul><p>B</p>C</ul>→ 解析为：<ul></ul><p>B</p><ul><li>C</li></ul>（序号重置）
后果不只是样式丢失：
-
ul li选择器完全不匹配 - 屏幕阅读器无法识别为列表，无障碍支持中断
- JS 动态追加
<li>后，DOM 结构与初始渲染不一致
<table>漏写<tbody>会让CSS和JS行为偏移
虽然 <tbody> 在 HTML 规范中是可选标签，但浏览器**必须**自动补全它。问题在于补的位置不可控，且补全逻辑不透明：
-
<table><tr><td>A</td></tr></table>→ 实际 DOM 是：<table><tbody><tr><td>A</td></tr></tbody></table> -
tr:first-child匹配的是<tbody>下的第一个<tr>，不是整个<table>的第一个子<tr> -
document.querySelector('table').tBodies[0].rows在 SSR 场景下可能为空，因为服务端没生成<tbody>，客户端 hydration 时层级对不上
某些 CSS 框架（如 Bootstrap Table）依赖显式 <tbody> 做 hover 样式隔离，漏写就会导致边框/悬停失效。
立即学习“前端免费学习笔记（深入）”；
验证嵌套是否合法不能靠肉眼或“能显示”
浏览器静默修正后 DOM 和源码差异极大，仅靠预览或 Elements 面板“看起来正常”无法判断结构是否合规：- 必须使用 W3C Markup Validation Service，它会直接指出类似
Element div not allowed as child of element p这类精准错误 - 禁用所有 CSS 后观察布局：如果块级元素突然塌陷、错位或垂直间距消失，大概率是父容器被意外截断（比如
<p>被强制闭合） - SSR 或 hydration 场景下，DOM 不一致往往就源于这类“不报错但改结构”的嵌套——它不会在控制台抛异常，却让 JS 查询失败、样式失效、无障碍崩溃
最常被忽略的一点：这些规则与你用不用 React、Vue 或是否服务端渲染无关。只要最终输出的是 HTML 字符串，浏览器就会按规范解析并修正。写的时候省事，调试时花三倍时间找原因。
