至

）来锚定。

日常开发中常见误用包括：

• 把仅用于样式的横幅区域写成
  。
• 把轮播图控制按钮容器包在
  里。

这些做法会造成语义断裂。正确的做法是：

• 标题是刚需：即使视觉上无需显示，也必须为
  添加语义化标题。推荐用CSS隐藏但保留给辅助技术，例如

  推荐商品

  。
• 层级要连贯：标题层级需与
  的嵌套关系保持一致。父级用

  ，子级用

  或更低，避免全部堆砌

  。

• 自检方法：若一时无法为区块想出标题，则很可能不应使用
  。

div 是唯一明确声明“此处无语义”的标签

在宣告“这里有主题”，而

则平静表示：“我仅划了一个框，不传递其它含义”。它本身不向浏览器、搜索引擎或读屏器提供内容信息。

对于这些工具来说，

几乎是透明的，它们真正关注的是附加的class、id或ARIA属性。因此，

的适用场景十分明确：

• CSS布局容器：如
  、

  。
• JavaScript操作锚点：如
  、

  。
• 纯功能/交互区域：如
  、

  。

需避免思维陷阱：不要被类名迷惑。例如

，类名虽含“section”，但判断标准始终是它是否拥有独立于文档其他部分的主题。

选错标签不影响渲染性能，但会干扰结构理解

从纯技术视角看，使用

或

在渲染性能、CSS选择器效率或DOM操作上无任何差异。核心差异在于发出的“语义信号”强度不同。

这种语义信号直接影响三件事：

• 浏览器能否生成清晰合理的文档大纲。
• 使用NVDA或VoiceOver等读屏软件的用户，能否通过标题级别导航快速跳转到关键逻辑区块。
• 搜索引擎（如Google）在抓取时，能否准确识别页面主干内容，而非让核心信息淹没在无意义的通用容器中。

反之，为了“语义化”而将所有

强行替换为

，会导致大纲中充斥无标题的“空章节”，反而降低读屏体验，Lighthouse可访问性评分也可能不升反降。

嵌套和替换没有安全边界，需按内容粒度重审

不存在“

里面套

就万事大吉”的取巧规则。每次标签选择都应基于根本性问题：当前这一层内容，是否天然可命名、可摘要，甚至可单独链接？

典型反面教材：

• 把整个页脚区域写成
  ——它有更专属标签
• 把轮播图左右箭头的控制容器用
  包裹——这是纯UI控件，无独立主题，用

  更诚实。
• 出现三层
  嵌套——可能应使用

  标签，或重新思考内容层级划分，而非堆砌语义标签。

现代前端开发中极易忽略的场景：编写组件时（如React中的function ProductCard() { return

...

}），若组件内部逻辑自洽，但对外不构成独立可命名主题，选择

作为根节点并非妥协，而是对其语义状态最精准的表达。

归根结底，语义化HTML不是标签堆砌游戏，而是对内容结构的诚实描述。正确使用

和

，就是为所有访问者（包括人和机器）铺就一条理解内容的清晰路径。