必须用仅当内容可独立命名、摘要并出现在大纲中；否则用更准确。判断标准是能否被rss抓取、搜索引擎独立展示或读屏软件列为大纲条目，且必须含–标题。
<section></section> 不是 <div> 的高级替代品，它只在内容能被单独命名、摘要、出现在大纲里时才该用；否则直接用 <code><div> 更诚实。
<h3>什么时候必须用 <code><section></section> 而不是 <div>
<p>判断标准就一个：这块内容能不能脱离当前页面，被 RSS 抓取、被搜索引擎当独立结果展示，或者被读屏软件列为大纲中的一级条目。比如产品页的「技术参数」<code><section></section> 配 <h2></h2>，用户点大纲就能跳过去；但「筛选条件栏」没独立语义，用 <div class="filter-bar"> 就行。
<p>常见错误现象：<code><section></section> 里没 <h2></h2>–<h6></h6>，或整个 套一层 <section></section>——此时浏览器和辅助工具完全忽略它的语义，等于白写。
- 标题必须是
<h2></h2>–<h6></h6>，<h1></h1>留给页面主标题 - 标题文本要真实，不能写 “模块一”“内容区” 这类占位符
- 多个
<section></section>应逻辑并列，不是父子嵌套关系（比如「客户评价」下再套<section></section>每条评论，就错了）
<article></article> 和 <section></section> 的边界在哪
<article></article> 是可独立分发、重用的内容单元，比如一条新闻、一篇博客、一个用户评论；它本身有完整上下文，能脱离页面存在。<section></section> 是为组织内容服务的语义分组，依赖上下文——它不能单独拿出来当 RSS 条目。
使用场景举例：整篇博客用 <article></article> 包裹；里面「引言」「实现细节」「性能测试」这三个部分，各自配 <h2></h2>，才用 <section></section>；而「相关文章推荐」列表如果每项都是独立 <article></article>，那外层用 <section></section> 合理，但别用 <article></article> 套一堆 <article></article>。
-
<article></article>内部可以有<header></header>、<footer></footer>，甚至嵌套<section></section> -
<section></section>里不能随便塞<article></article>，除非它真是一组并列的独立内容 - 不确定该用哪个？先问自己：“它能被 RSS 抓取吗？”能，优先
<article></article>；不能，再看是否满足章节划分标准
嵌套 <section></section> 容易踩的坑
嵌套本身合法，但极易破坏语义层级。例如在「客户案例」这个 <section></section> 下，又用 <section></section> 包每条客户反馈——这就混淆了“主题区块”和“独立条目”的区别，读屏软件会把每条反馈当成同级章节，而非子项。
真正需要嵌套的典型场景极少：比如某技术文档的「部署指南」<section></section> 下，再分「本地部署」<section></section>、「云环境部署」<section></section>，且每个子节都有明确 <h3></h3> 标题，这时嵌套才成立。
- 嵌套层级建议 ≤ 2 层，超过后 DOM 结构变复杂，CSS 选择器匹配成本上升（如
.page .section .section p） - 单个
<section></section>下子元素超 50 个，滚动时重排明显卡顿 - 纯为 JS 选中或加样式，直接用
<div class="xxx">，别硬套 <code><section></section>最常被忽略的点：语义标签不是装饰，而是契约——你写了
<section></section>，就得提供对应标题；写了<article></article>，就得让它能独立存在。没做到，不如不用。
