首先得澄清一个常见的概念混淆：HTML5的语义化标签，比如header、na v、main，它们本身并不是一个“框架”。它们是浏览器原生支持的标准HTML元素，无需引入任何第三方库或框架就能使用。这个概念如果搞混了，很容易在项目里走弯路，比如错误地引入polyfill，或者硬生生地用Ja vaScript框架的逻辑去套用这些原生标签。

哪些标签算语义化？别把 div 当语义标签用

语义化标签的核心价值在于“表达内容的角色”，而不是定义它的视觉样式。浏览器、屏幕阅读器、搜索引擎正是依靠这些标签来理解页面的结构层次。

几个最常用的语义化标签包括：

• header：表示一个区域或区块的页眉。注意，它不一定非得是整个页面的顶部，也可以嵌套在article或section内部。
• na v：专指主导航链接的集合。并非所有链接都该放在这里，例如页脚版权信息旁边的“关于我们”链接，通常就不算作主导航。
• main：页面中唯一的主体内容容器。每个页面只能有一个，并且它不能出现在article、aside、footer、header、na v这些标签的内部。

其他常用的还有article（代表独立完整的内容单元）、section（对内容进行主题分组）、aside（表示附属信息）、footer（区域或区块的尾部）。

这里有一个在早期项目迁移中常见的错误写法：

这种写法完全丧失了语义信息，同时也削弱了页面对无障碍访问技术的支持能力。

header 和 na v 能嵌套吗？怎么嵌才合理

答案是肯定的，可以嵌套，但必须符合内容本身的逻辑关系。一个常见的误区是，把na v简单地当作一个“导航栏组件”，生硬地塞进header里，而忽略了它是否真的是当前页面的主导航。

典型且合理的结构是这样的：一个header可能包含站点Logo、一个na v（主导航菜单），再加上搜索框或用户操作区。

不太推荐的做法是：在header里塞进多个na v（比如“产品导航”、“客户支持导航”、“开发者文档导航”各一个）。这种情况下，应该考虑将它们合并为一个逻辑清晰的主导航，或者使用na v配合aria-label属性来区分不同的导航区域。

另外，na v也可以独立于header存在，例如侧边栏导航，或者文章内部的目录导航。

来看一个正确的示例：

  
我的博客
  
    首页
    文章
  

main 标签的隐藏陷阱：SEO 和辅助技术最在意它

main标签的作用远不止“看起来像主要内容”那么简单。它的存在，直接影响到搜索引擎如何分配抓取权重，以及屏幕阅读器用户的跳转效率（例如，JAWS屏幕阅读器用户可以使用M快捷键直接跳转到main区域）。

因此，使用时有几个必须遵守的规则：

• 必须确保每个页面有且仅有一个main标签，重复会导致辅助技术行为异常。
• 它不能包裹header、footer、na v等外围结构——这些本就不属于“主体内容”。
• 在服务端渲染（SSR）或静态生成时，如果页面模板和布局组件各自输出了一个main标签，拼接后就会产生多个，这会直接破坏语义的兼容性。

还有一个历史兼容性问题需要注意：IE浏览器完全不支持main标签，不过可以通过添加role="main"属性来补充语义（当然，对于现代项目，通常已不再考虑IE兼容）。

实际项目里最容易被忽略的一点

语义化标签本身并不带有默认的CSS样式，但不同浏览器的处理方式仍有细微差别。例如，部分浏览器会对main标签施加隐式的display: block样式，而旧版本的Safari对na v标签的display属性处理也曾出现过偏差。

比样式差异更关键的，是语义的精确性。很多人记得写header标签，却忘了给它加上role="banner"属性（虽然HTML5中非必需，但在某些老旧的屏幕阅读软件中，这能提升识别率）。

说到底，真正的难点不在于把标签写对，而在于持续校验这些标签是否与内容的真实意图保持一致。举个例子，一个“登录弹窗”里的标题区域，其实不应该使用语义化的header标签，更合适的做法是使用div配合role="heading"和aria-level属性来定义。这需要开发者对语义和无障碍规范有更深的理解。