<article> 用于可独立分发、有完整语义和元信息的内容单元，如博客文章、新闻稿、用户评论；<section> 表示同一主题下的逻辑分组，须带标题，强调内容归类而非独立性。
article 适合独立分发的内容单元
如果你的内容能单独被 RSS 订阅、被搜索引擎作为独立条目索引、或脱离当前页面仍保持完整意义，就该用 <article>。比如博客文章、新闻稿、用户评论、产品卡片——它们各自有标题、作者、发布时间等元信息，逻辑上可“拎出来”单独存在。
常见误用是把整个文章页的正文区域包成一个 <article>，其实它更强调“可复用性”和“可移植性”。一个页面里可以嵌套多个 <article>，甚至 <article> 内还能再嵌 <article>（如评论区里的每条评论）。
- 典型场景：
<article>用于博客列表页的每篇文章卡片、论坛帖子、微博式短内容 - 不适用场景：页面顶部导航栏、侧边栏、页脚版权区——这些不是“内容”，而是“界面结构”
- 注意：
<article>默认没有 ARIA role，但语义上等价于role="article"，屏幕阅读器会据此调整朗读方式
section 表示主题明确的内容分组
<section> 的核心是“同一主题下的内容集合”，它不强调独立性，而强调逻辑归类。比如一篇文章里的“背景介绍”“实验方法”“结果分析”三个部分，各自用 <section> 包裹更准确；再比如产品页里的“规格参数”“用户评价”“售后服务”区块。
关键判断标准：删掉这个 <section>，里面的内容是否还自然属于同一话题？如果答案是“否”，那它可能不该用 <section>，或者需要拆得更细。
立即学习“前端免费学习笔记（深入）”；
- 必须带标题（
<h1>–<h6>）才推荐使用<section>，否则语义弱化，不如直接用<div> - 不要用
<section>替代样式容器：仅为了加 margin/padding 或 flex 布局而套一层<section>是滥用 - 兼容性无问题，但旧版 IE 不识别语义，需配合
document.createElement("section")或 polyfill（现代项目基本不用考虑）
嵌套关系与替代边界
<article> 和 <section> 可以互相嵌套，但目的不同。例如一篇技术文档页面，外层是 <article>（整篇文档可被单独引用），内部用多个 <section> 划分章节；反过来，一个新闻聚合页里，每个 <article> 下也可能包含若干 <section>（如“事件经过”“各方回应”“后续进展”）。
真正容易混淆的是和 <div> 的取舍：当内容既不满足 <article> 的独立性，也不具备 <section> 的主题聚类特征时，老老实实用 <div>——语义化不是强制指标，可读性和维护性才是。
- 错误写法：
<section> <p>这是页脚联系方式</p> </section>
（页脚不是“主题内容分组”，只是 UI 区块） - 正确思路：先问“这段内容有没有独立意义？”→ 否 → 再问“它是否和其他内容共享一个明确主题？”→ 否 → 用
<div> - 标题层级影响：每个
<section>或<article>都会形成新的大纲上下文，浏览器开发者工具的“Accessibility”面板能直观看到嵌套后的结构树
实际项目中怎么选：看内容生命周期
最省心的判断法：想象这段内容要被 API 输出、被 CMS 导出、被第三方爬虫抓取——如果它需要保留自身元数据（ID、author、published_time），优先 <article>；如果它只是当前页面里为阅读体验做的视觉/逻辑分段，且不会单独流通，优先 <section>。
真实项目里，<article> 出现频率远低于 <section>，尤其在后台系统、管理界面、表单流程页中，几乎用不到 <article>。别为了“语义化达标”硬凑，反而让结构失真。
- CMS 类系统：文章列表项 →
<article>；编辑页的“基础信息”“SEO 设置”“权限配置”Tab 区域 →<section> - 电商详情页：“商品描述”“规格参数”“买家秀” → 三个
<section>；每一条买家秀 →<article> - 最容易忽略的一点：即使用了语义标签，若标题层级跳变（比如
<section>里直接跟<h3>却没<h2>），辅助技术仍会困惑——语义标签和 heading 结构必须协同
