用于可独立分发、有完整语义和元信息的内容单元，如博客文章、新闻稿、用户评论； 表示同一主题下的逻辑分组，须带标题，强调内容归类而非独立性。

article 适合独立分发的内容单元

如果你的内容能单独被 RSS 订阅、被搜索引擎作为独立条目索引、或脱离当前页面仍保持完整意义，就该用 。比如博客文章、新闻稿、用户评论、产品卡片——它们各自有标题、作者、发布时间等元信息，逻辑上可“拎出来”单独存在。

常见误用是把整个文章页的正文区域包成一个 ，其实它更强调“可复用性”和“可移植性”。一个页面里可以嵌套多个 ，甚至 内还能再嵌 （如评论区里的每条评论）。

• 典型场景： 用于博客列表页的每篇文章卡片、论坛帖子、微博式短内容
• 不适用场景：页面顶部导航栏、侧边栏、页脚版权区——这些不是“内容”，而是“界面结构”
• 注意： 默认没有 ARIA role，但语义上等价于 role="article"，屏幕阅读器会据此调整朗读方式

section 表示主题明确的内容分组

的核心是“同一主题下的内容集合”，它不强调独立性，而强调逻辑归类。比如一篇文章里的“背景介绍”“实验方法”“结果分析”三个部分，各自用

包裹更准确；再比如产品页里的“规格参数”“用户评价”“售后服务”区块。

关键判断标准：删掉这个

，里面的内容是否还自然属于同一话题？如果答案是“否”，那它可能不该用

，或者需要拆得更细。

立即学习“前端免费学习笔记（深入）”；

• 必须带标题（

  –

  ）才推荐使用
  ，否则语义弱化，不如直接用
• 不要用
  替代样式容器：仅为了加 margin/padding 或 flex 布局而套一层
  是滥用
• 兼容性无问题，但旧版 IE 不识别语义，需配合 document.createElement("section") 或 polyfill（现代项目基本不用考虑）

嵌套关系与替代边界

和

可以互相嵌套，但目的不同。例如一篇技术文档页面，外层是 （整篇文档可被单独引用），内部用多个
划分章节；反过来，一个新闻聚合页里，每个 下也可能包含若干
（如“事件经过”“各方回应”“后续进展”）。

真正容易混淆的是和 的取舍：当内容既不满足 的独立性，也不具备

的主题聚类特征时，老老实实用 ——语义化不是强制指标，可读性和维护性才是。
• 错误写法：

  
    
  这是页脚联系方式
  

  （页脚不是“主题内容分组”，只是 UI 区块）
• 正确思路：先问“这段内容有没有独立意义？”→ 否 → 再问“它是否和其他内容共享一个明确主题？”→ 否 → 用
• 标题层级影响：每个
  或 都会形成新的大纲上下文，浏览器开发者工具的“Accessibility”面板能直观看到嵌套后的结构树

实际项目中怎么选：看内容生命周期

最省心的判断法：想象这段内容要被 API 输出、被 CMS 导出、被第三方爬虫抓取——如果它需要保留自身元数据（ID、author、published_time），优先 ；如果它只是当前页面里为阅读体验做的视觉/逻辑分段，且不会单独流通，优先

。

真实项目里， 出现频率远低于

，尤其在后台系统、管理界面、表单流程页中，几乎用不到 。别为了“语义化达标”硬凑，反而让结构失真。
• CMS 类系统：文章列表项 → ；编辑页的“基础信息”“SEO 设置”“权限配置”Tab 区域 →
• 电商详情页：“商品描述”“规格参数”“买家秀” → 三个
  ；每一条买家秀 →
• 最容易忽略的一点：即使用了语义标签，若标题层级跳变（比如
  里直接跟
  却没
  ），辅助技术仍会困惑——语义标签和 heading 结构必须协同