HTML文档结构之容器嵌套的逻辑合法性

HTML嵌套是否合法取决于是否符合W3C内容模型，而非能否渲染；如<p>仅允许phrasing content，嵌套<p>会触发浏览器自动闭合，破坏语义与可访问性。

HTML容器嵌套是否“合法”，不看它能不能渲染出来，而看它是否符合 W3C 定义的 content model（内容模型）——浏览器能容错显示，不代表结构是对的。

哪些标签里绝对不能放 <p>
<p>不是所有块级容器都接受 <code><p>。最典型的是 <code><p></p>：它只允许 phrasing content（短语内容），<p> 属于 <em>flow content</em>，直接塞进去会触发浏览器自动修复。
<ul>
<li>
<code><p></p>
<p>xxx</p> 实际被解析为 <p></p>
<p><span>立即学习</span>“<a href="https://pan.quark.cn/s/cb6835dc7db1" style="text-decoration: underline !important; color: blue; font-weight: bolder;" rel="nofollow" target="_blank">前端免费学习笔记（深入）</a>”；</p>
<p>xxx</p>，DOM 结构已变

<h1></h1>～<h6></h6>、<dt></dt> 同理，它们语义上只承载标题或定义项文本，不能当布局盒子用

<li> 可以包 <p>，但多数情况是冗余——给 <code><li> 加 margin/padding 就够了

<main></main> 为什么不能套在 <section></section> 里

<main></main> 是页面中唯一、可独立分发的主内容区域，W3C 明确禁止它作为任何节元素（<section></section>、<article></article>、<nav></nav> 等）的子元素。

• 错误写法：<section><main>...</main></section> → 语义失效，屏幕阅读器可能跳过 <main></main> 的快捷导航
• 正确逻辑：<main></main> 应直接位于 下；它内部可以再用 <section></section> 划分小节，但不可倒置
• 影响不止于可访问性：SEO 工具可能降权该区块，Lighthouse 也会报 “<main></main> not at top level”

<ul></ul> 和 <ol></ol> 只认 <li> 当儿子

<ul></ul> 和 <ol></ol> 的合法子元素只有 <li>。哪怕你只是多敲了一个换行、一个空格，或者把 <p></p> 直接扔进去，浏览器就会中断当前列表、新建一个列表来“兜底”。

• 错误写法：<ul>
<p>Item one</p>
<li>Item two</li>
</ul> → 解析为 <ul></ul>
<p>Item one</p>
<ul><li>Item two</li></ul>
• 后果：序号重置、CSS 选择器（如 ul > p）完全失效、辅助技术无法识别列表关系
• 若需段落式列表项，用 <li><p>...</p></li>，别绕开 <li>

嵌套超三层时，第一反应不该是“怎么写”，而是“该不该用 <p>”
<p>每多一层 <code><p>，就多一层语义真空和维护成本。深层嵌套往往暴露的是结构设计问题，而非布局需求。
<ul><li>检查这层 <code><p> 是否有明确职责：是为 CSS 提供作用域？为 JS 挂载点？还是为语义留 hook？如果答案模糊，大概率该删
<li>优先升维为语义标签：<code><p class="nav"><p class="logo"></p></p> → 改成 <nav><h1 class="logo"></h1></nav>

需要 flex 布局？直接给 <section></section> 或 <article></article> 加 display: flex，别为了“让 flex 生效”硬套一层 <p>

<p>真正难的不是嵌套语法，而是每次敲下 <code><p> 时，能否立刻说出它存在的唯一理由。浏览器不会报错，但语义断层会在自动化测试、读屏器、SEO 工具里集中爆发——而且往往发生在上线后。</p>