”。其实不然。它本身不负责布局，也不提供任何默认的视觉效果。它的核心使命非常纯粹：向浏览器、搜索引擎以及屏幕阅读器清晰地宣告——“注意了，这里是一块拥有独立主题、能够被单独命名和导航的内容区域”。

什么时候必须用

而不是

判断标准其实很直接：问问自己，这块内容是否天然带有一个可以命名的主题，并且理应出现在文档大纲里？

• 产品详情页里的「核心功能」、「客户案例」、「技术参数」——这些部分每一个都该用
  包裹。因为它们各自都有明确的

  标题，完全可以被单独链接或提取摘要。

• 首页上并列展示的三篇最新文章——每篇文章本身应该是
  ，而不是

  ；而包裹这三篇文章的整个“最新文章”区块，才是一个

  。
• 页脚里的社交媒体图标列表、导航栏的下拉菜单、表单里的分组字段——这些更多是出于布局或交互目的的分组，用

  加上恰当的 class 来描述会更准确。

• 这里有个很实用的自检方法：如果你给某块内容加上了
  标签，却一时想不出该给它起个什么标题，那大概率说明，它根本就不该是一个

  。

必须配标题，否则语义断裂

一个没有配备

到

标题的

，在辅助技术面前几乎等同于“隐身”。NVDA 或 VoiceOver 等屏幕阅读器不会把它列为可导航的节点，自动大纲提取工具也无法识别它，甚至连基于结构的 CSS 作用域都会失去锚点。

• 错误写法：

  这部分讲性能优化

  —— 缺少标题，语义完全失效。
• 正确写法：

  性能优化策略

  这部分讲性能优化

• 当进行嵌套时，子级的
  也必须拥有自己的标题，并且标题的层级要与之匹配（例如，父级用

  ，子级就用

  ）。

• 标题不一定非得是纯文字。像

  ⚙️配置说明

  这样的组合，同样是一个有效的标题。

和

的边界在哪

这可能是最让人困惑的地方。简单来说，

代表的是“可以独立分发、重复使用”的内容单元，比如一篇完整的博客文章、一条用户评论或一则新闻。而

则是为组织内容服务的语义分组，它依赖于所在的上下文而存在。

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

• 在一篇博客正文（一个
  ）内部，其“引言”、“原理分析”、“代码示例”、“总结”这几个部分，就可以是四个并列的

  。
• 但是，文章下方的每一条用户评论本身，应该是一个
  ，而不是

  ；而容纳所有这些评论的“评论区”容器，才是一个

  。
• 滥用
  去替代

  ，可能会导致 RSS 抓取失败、社交媒体分享卡片丢失关键的元数据。
• 另外，对于已经有专用语义标签的区域（比如 、

话说回来，标题缺失这个问题带来的连锁反应，远比想象中严重。它不仅会让屏幕阅读器用户跳过整块内容，还会导致 CSS 中那些基于结构的选择器（例如 section h2 + p）失效，甚至影响 document.querySelectorAll('section') 这类操作返回结果的语义可信度。所以，别只是为了“让代码看起来更语义化”而随手加上

。不妨先问自己一个最实在的问题：用户能不能凭借一个标题，直接定位并跳转到这块内容？如果答案是肯定的，那再用它也不迟。