必须用article，不能用section；每条评论都是独立可提取、可订阅、可转发的内容单元，须自足且含header（含h3–h6标题或元信息），嵌套合法但归属必须明确。
多级评论该用 article 还是 section？
必须用 article，不能用 section。每条评论都是独立可提取、可订阅、可转发的内容单元——哪怕只有一句话，它也具备完整的语义自足性。而 section 是为“同一主题下的逻辑分组”服务的，比如“全部回复”这个容器本身可以是 section，但里面每一条回复必须是 article。
常见错误是把整个评论区写成一个 section，再用一堆 div 套评论；或者把父评论和子评论都塞进同一个 article 里——这直接破坏了“每条评论可独立存在”的前提。
-
article支持嵌套：子评论作为父article的子元素，是完全合法且推荐的写法 - 嵌套层级不限，但每层
article必须含至少一个标题（h2–h6）或元信息（如<time></time>、作者<cite></cite>） - 若某条评论缺失标题，浏览器不会报错，但屏幕阅读器可能跳过它，Lighthouse 也会提示“Missing heading”
header 在嵌套评论中的归属陷阱
每个 article 都应有自己的 header，用来包裹该条评论的标题、作者、时间等元数据。关键不是“有没有 header”，而是它是否归属于当前 article ——也就是必须紧贴在 article 开始标签之后，且不能被其他无语义容器（如 div、span）隔开。
典型翻车现场：<article><div class="comment-wrapper"><header>...</header></div></article>。这个 header 实际上归属到了那个空 div，而非 article，语义断裂。
立即学习“前端免费学习笔记（深入）”；
- 正确结构：
<article><header><h3>Re: 楼主观点</h3><cite>用户A</cite><time datetime="2026-08-24">昨天</time></header><p>我补充一点…</p></article> - 嵌套时，子
article的header仍需独立存在，不可复用父级的header - 不要为了省代码把多个
header合并成一个——每个article的上下文是独立的
用 nav 处理“回复”“点赞”“折叠”这类操作按钮？
不能。这些按钮不属于导航链接集合，nav 只适用于跳转类行为（如“返回顶部”“跳到楼中楼”），而评论区的操作按钮本质是交互控件，应使用 form、button 或带 role="toolbar" 的 div。
强行套 nav 不仅让屏幕阅读器误读为“导航区域”，还会干扰 Lighthouse 的 Landmark 检测，导致“Navigation landmark found without link elements”警告。
- “回复”按钮：放在
article底部，用<button type="button">回复</button> - “展开子评论”：用
<button aria-expanded="false" aria-controls="replies-123">查看 3 条回复</button>，配合id="replies-123"指向子article容器 - 整条评论区的“排序方式切换”可以放
nav，因为它是一组跳转到不同视图的链接
为什么 aside 不适合放“相关评论”或“热门回复”？
因为它们与当前评论内容强关联，不是“非必需的补充信息”。aside 的语义边界很窄：广告、引用来源、术语解释、作者简介——这些内容拿掉不影响主干理解。而“热门回复”本质是评论流的一部分，属于内容主体延伸。
更严重的问题是，把热门回复塞进 aside 后，它会被屏幕阅读器归类为“侧边栏”，用户无法通过“进入 main 区域”自然触达，SEO 也会降权。
- 正确做法：将“热门回复”作为独立
article插入到主评论流中，或用section包裹（前提是该section有明确标题，如<h2>热门讨论</h2>） - 如果真要放广告或第三方推荐，且确定它与当前评论无逻辑绑定，才可用
aside，但必须确保其父容器是article或section，而非悬空 - 动态加载的“更多回复”建议用
section+loadmore按钮，避免用aside模拟懒加载容器
最易被忽略的是嵌套层级中 header 和 article 的归属关系——它不取决于写了几个标签，而取决于 DOM 树中谁直接包裹谁。组件化框架里模板插槽、SSR 渲染顺序、JS 动态插入都可能悄悄切断这个归属链，一不留神就让整层嵌套失去语义。
