用于可独立分发、有完整语义和元信息的内容单元，如博客文章、新闻稿、用户评论； 表示同一主题下的逻辑分组，须带标题，强调内容归类而非独立性。
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 结构必须协同
- 标题层级影响：每个
- 不要用
