article嵌套合法但需谨慎：html标准允许，浏览器不拦截，但语义层级、辅助技术解析和seo会受损；评论区用article须满足可独立分发、复用、索引的“三可”原则；回复内容通常不应再嵌套article。
article 嵌套是否合法？浏览器不拦，但语义会崩
HTML 标准允许 article 嵌套另一个 article，浏览器也不会报错或阻止渲染。但这不等于“可以随便嵌套”。真正的问题出在语义层级和辅助技术解析上：
- 屏幕阅读器、文档大纲生成器、RSS 抓取器都依赖嵌套关系推断内容结构
- 若子
article不是父article的逻辑独立副本，它们就会被当作同级主内容处理，导致标题跳变、导航混乱、SEO 权重错配
常见错误现象：
- Chrome DevTools 的 “Accessibility” 面板提示 “Document outline has unexpected jump”
-
document.querySelectorAll('article')返回一堆节点，但 JS 逻辑无法区分“主文”和“评论”边界 - RSS 订阅器把每条评论单独抓成一条新条目，而非作为主文附属内容
评论区怎么用 article？必须满足“三可”原则
评论区是 article 最典型也最容易误用的场景。关键判断不是“它看起来像一篇文章”，而是它是否满足“三可”：
- 可独立分发（复制整条评论到微博/邮件，仍有意义）
- 可独立复用（被其他页面引用、嵌入、转发）
- 可独立索引（搜索引擎愿为它生成独立摘要页）
实操建议：
- 每条评论应包裹完整信息：至少一个
<h3></h3>或<h4></h4>（作者+时间）、一段主体<p></p>或<div>（含格式化文本）、可选 <code><footer></footer>（操作按钮、点赞数） - 整个评论列表本身不能用一个
article包裹——它只是容器，应使用section或div - 父级文章用
article，其内部直接子元素是header、main、footer或多个并列的子article（即每条评论），而不是div+ class 模拟结构 - 它依附于原评论存在，脱离上下文常无完整语义（比如“同意楼上”“这个链接失效了”）
- 几乎无法被 RSS 单独订阅，也不适合被搜索引擎独立索引
- 强行用
article会导致三层嵌套（主文 → 评论 → 回复），大纲层级断裂，读屏软件反复播报“文章” - 一级评论：用
article - 其下的回复列表：用
section或ol/ul（若按时间/热度排序） - 每条回复：用
li，内部可含header（作者+时间）、p（内容）、footer（操作） - 若某条回复本身已是一篇长评（带标题、多段落、作者署名、发布时间），且业务上允许它被单独引用——这时才考虑提升为子
article，但需确保它出现在父评论的语义上下文中，而非硬塞进li里 - W3C 验证器会报 “Element article not allowed as child of element article” —— 实际是校验器在检查嵌套合法性，而非语法错误
- 使用
dangerouslySetInnerHTML注入字符串时，若字符串里article缺少显式闭合标签（如写成<article></article>），服务端渲染和客户端 hydrate 会因解析差异导致 DOM 不一致 - 模板引擎（如 Handlebars、EJS）若自动转义或截断 HTML，可能让嵌套的
article标题丢失，造成语义残缺 - 所有
article标签都写完整开闭（<article>...</article>），禁用自闭合写法 - 在服务端预渲染前，用
DOMParser或类似工具验证嵌套结构合法性 - 若评论数据来自 CMS 或第三方 API，入库前就校验每条是否含标题节点，避免前端 fallback 渲染出空
article
回复内容（二级评论）还能套 article 吗？通常不该
用户对某条评论的“回复”，绝大多数情况不构成独立内容单元：
更合理的结构：
模板与框架里嵌套 article 的坑
Next.js、Nuxt 或 SSR 模板中动态插入含 article 的 HTML 时，容易触发 hydration 错误或结构警告：
务必做到：
嵌套本身不难，难的是每次写 <article></article> 之前，得真问一句：它现在是不是一个能自己活下来的内容？不是装饰，不是分区，不是为了加 class 方便写 CSS——是内容本身的粒度决定了要不要用它。
