因为合法但无语义，团队协作依赖标签明确结构而非猜测class名；须按功能角色使用：如为顶层头部容器、仅包跳转链接、唯一且为直系子元素、必带以上标题，否则应改用。

为什么浏览器不报错，但团队协作时总被叫去改代码？

因为

本身完全合法，浏览器只管渲染，不管语义。但团队里没人靠猜 class 名来理解结构——class="header" 和 class="top-nav" 看似能用，一旦命名不统一（比如有人写 class="head"），后续维护就变成考古现场。真正触发协作成本的，不是语法错误，而是语义模糊。

、

、

这些标签到底该套在哪？

不是“看起来像头部就用

”，而是看它是否承担页面或区块的**顶层功能角色**：

• ：必须是页面/section 的**第一层容器级头部**，含 logo、主导航、搜索框等；单个按钮或标题栏不算
• ：只包**跳转链接集合**，比如顶部菜单、页脚链接组、文章末尾的“上一篇/下一篇”；登录按钮、筛选控件、搜索框不能塞进去
• ：一个页面最多一个，且必须包裹**唯一核心内容流**；侧边栏、广告位、页脚都得在外面
• ：必须自带
  或更高级别标题，删掉这个标签后，别人看不出这块讲的是什么主题——那就该换

什么时候还非得用

？

没被淘汰，它只是退回到“纯视觉分组”的本职岗位：

• 仅用于添加 margin/padding、背景色等样式隔离，内容本身无独立主题
• 作为 CSS Grid/Flex 容器的 wrapper，且内部没有语义层级需求
• 动态插入的 DOM 节点（如 JS 渲染弹窗、提示框），暂时无法预判语义时可先用
  ，但上线前应评估是否可替换为

  或
• 嵌套过深时（比如
  ），中间层若无明确标题和独立性，不如用
  降噪

  检查自己有没有真正在用语义化，就看这三点

  写完 HTML 后快速过一遍：

  

  HTML Text Extract

  从HTML页面（URL、文件或标准输入）中提取主体内容文本，去除导航、页脚、广告和模板文本。可直接传递给readability_check或其他文本工具。

  下载

  • 把所有 class 名删掉，只留标签——还能否一眼看出导航在哪、正文在哪、底部在哪？不能，说明语义没立住
  • 用 Chrome 开发者工具切换到 Lighthouse → Accessibility 报告，如果 “
    元素缺少可访问名称” 或 “
    缺失” 频繁出现，就是硬伤
  • 用键盘 Tab 键浏览页面，能否按逻辑顺序从导航→主内容→页脚自然跳转？卡在一堆
    里出不来，说明辅助技术根本识别不了结构

    语义化不是加标签，是给内容定身份。最常被忽略的，是把

    当

    用却不配标题，或者把多个

    放一起却不加 aria-label 区分用途——这些细节，比选对第一个标签更影响实际体验。