罗漫最近帮一个朋友重构他几年前写的个人网站，打开源代码一看，满屏都是<div class="header">、<div class="content">、<div class="footer">、<div class="article-item">，样式和脚本全靠class名硬撑，结构乱得像没整理过的衣柜。我跟他说，你这些class命名其实已经做对了一半——你在试图用名字描述内容，但浏览器和搜索引擎并不认你的class，它们只认标签。HTML5新增的语义化标签，就是官方给你的“标准衣柜隔板”，让你不再靠自觉去维护页面结构。
这篇课程围绕HTML5语义化标签展开，适合已经掌握HTML基础标签、想提升页面结构质量的开发者，也适合那些写了很多div但总觉得哪里不对的人。读完你不仅会认识header、nav、main、article、section、aside、footer这些核心结构标签，还会搞懂figure、mark、time、progress、details这些补充型语义标签怎么用、什么时候用、什么时候别硬用。更重要的是，我会告诉你在真实项目中怎么改造旧页面，以及浏览器兼容这块到底要操多少心。
1. 在div海洋里挣扎过的开发者，都该认识这组标签
1.1 语义化到底解决了什么问题
先看一段在HTML4时代几乎天天见到的代码：
html复制<div class="header">
<div class="logo">...</div>
<div class="nav">...</div>
</div>
<div class="main">
<div class="content">...</div>
<div class="sidebar">...</div>
</div>
<div class="footer">...</div>
这段结构对能看懂class命名的人来说，勉强可读。但问题在于：class的命名是“人定的规矩”，不同的开发者有不同的命名习惯。你的项目里叫header，别人的项目里可能叫top、banner、page-head，搜索引擎爬虫和屏幕阅读器拿到这些class时是懵的——它们只能靠猜。
HTML5语义化标签解决的核心问题，就是“让标签本身说人话”。<header>就是页眉，<nav>就是导航，<main>就是主体内容，<footer>就是页脚。浏览器、搜索引擎、辅助工具拿到HTML后，不需要理解你的class命名体系，直接通过标签就能判断出每个区块的职责。
这个转变的本质，是把“结构性描述”从“样式命名约定”提升为“标准化的接口”。就像你给朋友指路，说“在贴着蓝色标志的建筑旁边右转”，远不如“在邮局旁边右转”靠谱——因为蓝色标志可能被换掉，但邮局是所有人都认识的公共标识。
1.2 机器可读性与可访问性：不只是给搜索引擎看的
很多人对语义化的理解停留在“方便SEO收录”这个层面，这其实只是冰山一角。语义化标签更重要的价值在于可访问性（Accessibility，常缩写为A11y）。
屏幕阅读器（比如NVDA、VoiceOver）在读取页面时，会利用HTML标签构建页面的“文档大纲”或“地标区域”（landmark regions）。当页面中使用了<main>标签，视障用户可以通过快捷键直接跳到主体内容区域，跳过重复的导航；使用<nav>标签，用户可以快速在多个导航区域之间切换；使用<aside>标签，读屏软件会提示“补充信息区域”，并允许用户决定是否阅读这部分内容。
我在实际测试中就遇到过这样的案例：一个使用div+class构建的页面，读屏软件只会机械地读出每一个文本节点，用户无法通过快捷键在区块间跳转，整个浏览体验非常冗长；改造为语义化标签之后，读屏体验立刻上了一个台阶。所以如果你开发的是面向公众的网站，语义化不是“加分项”，而是“基础要求”。
1.3 不只是HTML规范，也是团队协作的沟通语言
还有一个容易被忽视的价值：语义化标签能显著降低团队协作的沟通成本。一个新人接手你的项目，如果看到的全是<div class="wrapper">、<div class="item">这类中性标签，他必须逐个查看CSS和上下文才能理解区块职责；但如果页面用的是<article>、<section>、<aside>，结构一目了然，新人甚至不需要看CSS就能在脑海里勾勒出页面的骨架。
我自己维护过几个“三五年陈年老项目”，最深切的体会是：用div堆出来的页面，半年后再看就像看别人写的代码；用语义化标签搭出来的页面，即使过了很久，结构意图依然清晰。这还谈不上什么高级技巧，只是一种对未来的自己负责的编码习惯。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 页面骨架五件套：header、nav、main、aside、footer的正确用法
2.1 header和footer：可以多，但不能乱
很多人以为<header>就是页面顶部、<footer>就是页面底部。这个理解不算错，但不完整。严格来说，<header>和<footer>不光是“页面级”标签，它们也可以用在<article>、<section>内部，充当区块的头部和尾部。
比如一篇文章的卡片区域：
html复制<article>
<header>
<h2>文章标题</h2>
<p>发布时间：<time datetime="2025-01-15">2025年1月15日</time></p>
</header>
<p>正文内容……</p>
<footer>
<p>标签：<a href="#">HTML5</a> <a href="#">语义化</a></p>
</footer>
</article>
在这个例子里，<header>和<footer>是<article>这个区块的头部和尾部，而不是整个页面的。注意<header>和<footer>在整个文档中不需要与<body>同级，它们可以嵌套在任意有“独立语义”的容器中。
但有几个容易踩的坑：
<header>不能放在<footer>或<address>内部。<footer>不能放在<header>或<address>内部。<address>标签用于提供联系信息，通常放在<footer>里，但它不是“加粗斜体”的替代品。
项目开发中让人比较纠结的场景是：到底什么时候用<div>包一层，什么时候用<header>、<footer>包一层？我的判断标准很简单——如果这个区域有“引入性内容”（比如标题、作者、发布时间、目录），就用<header>；如果有“收尾性内容”（比如版权、联系方式、相关阅读、转载许可），就用<footer>；如果纯粹是为了布局方便、加样式或包一组无关元素，那就继续用<div>，别硬套语义标签。
2.2 main：一个页面只能有一个，且不能“隐藏”它
<main>应该是语义化标签里最容易理解也最容易出错的一个。它代表页面主要内容的容器。规范要求：
- 一个页面只能有一个
<main>。 main不能是<article>、<aside>、<footer>、<header>、<nav>的后代。
为什么要禁止<main>嵌套在<article>里面？因为<article>代表一个独立的可复用内容单元，如果它出现在多个页面（比如文章摘要列表页），每个页面都会继承一个“main”，但整个页面真正的入口只应该有一个。禁止嵌套就是为了避免语义混乱。
另一个容易被忽略的细节是：不要把<main>用display: none或visibility: hidden隐藏起来。这会导致读屏软件和搜索引擎认为页面没有主要内容。如果出于某种需求需要隐藏内容，请改用hidden属性，并确认它不是<main>。这一点在单页应用（SPA）中尤其重要——很多人习惯用display: none/duration来切换页面区域，导致<main>长期处于不可见状态，对SEO和可访问性都是灾难。
2.3 nav：不是所有链接都配叫导航
<nav>标签用于标记“主要导航链接”的区域。注意“主要”这个词。规范的本意是，<nav>应该留给页面中最重要的链接分组，比如主导航菜单、目录、分页控件。而页脚里那一排友情链接、版权页里的链接、文章中的普通超链接，这些不需要放进<nav>。
如果一个页面里有多个<nav>，通常需要借助aria-label来区分，比如：
html复制<nav aria-label="主导航">
<ul>
<li><a href="/">首页</a></li>
<li><a href="/blog">博客</a></li>
</ul>
</nav>
<nav aria-label="页脚导航">
<ul>
<li><a href="/about">关于我们</a></li>
<li><a href="/contact">联系我们</a></li>
</ul>
</nav>
aria-label的意义是给读屏软件一个可读的名称，否则两个<nav>在辅助技术下无法区分。这虽然不是HTML5语义标签本身的功能，但和语义化配套使用几乎是刚需，尤其是在大型站点中。
2.4 aside：它是补充，不是装饰
<aside>表示与主内容“仅间接相关”的内容区块。典型场景是：
- 侧边栏（但也不是所有侧边栏都该用aside，如果侧边栏里的内容是直接支撑主文的，反而应该用section）。
- 文章中的“相关阅读”“关于作者”区域。
- 广告位。
需要注意：<aside>在页面中出现的位置不同，它的语义范围也不同。如果它位于<article>内部，那么它的内容必须与这篇<article>相关；如果它位于页面正文外部（比如页面侧栏），则它的内容应与整个页面相关。
我见过不少人把所有侧边栏一律写成<aside>，这其实未必对。如果你的“侧边栏”里放的是最近文章列表、热门标签云这种和当前页面内容没有直接关联的全局区块，用<aside>没错，因为它和页面主题是“间接相关”。但如果是一个产品详情页里同时出现的“搭配购买”推荐，它跟当前产品密切相关，更合理的做法是放在<section>里，而不是<aside>。
3. 内容容器三兄弟：section、article、figure怎么选才不纠结
3.1 section和article的区别：核心是“能否独立分发”
<section>和<article>是平时最容易混淆的一对标签。简单来说：
<article>：代表一个独立、完整、可单独分发或复用的内容单元。比如一篇博客文章、一条新闻、一条评论、一个论坛帖子。即使它脱离整个页面，单独放到RSS里，依然有完整的意义。<section>：代表一个主题性分组。它通常需要一个命名性的标题（h1-h6），表示这个分组讲的是同一个主题下的内容。
举个例子看清楚。一个“关于我们”页面，可能分为“公司简介”“发展历程”“团队介绍”三块内容，这三块应当用<section>包裹，因为每块都完整且独立存在于该页面的主题内；而一个新闻网站的首页，每一条新闻摘要都应当用<article>包裹，因为每一条新闻都可以单独分发到别处。
判断的办法：如果把当前内容剥离当前页面，单独放到一个空页面或订阅源里，读者依然能看懂，不会问“这是哪来的”，那就是<article>；如果剥离后只是一堆碎片，必须依赖页面环境才能理解，那就只能是<section>。
还有一个很实用的备选判断：这块内容是不是一个完整的“复合体”？文章有自己的标题、作者、发布时间、正文，这是article的标准姿势。一个只有几段文字的产品卖点说明，即使有标题，也未必撑得起article的完整性，用section更合适。
3.2 该用section却用了div，该用div却用了section，都是有问题的
我在代码评审中经常看到两类误用：
第一类，把<section>当作带样式的容器，只要是一个块就用section包。这会让文档大纲变得非常嘈杂，读屏软件会把每个section都读成“区域”，结果就是到处都是区域，等于没有区域。<section>必须包含一条明显的“主题线”，让用户理解“这一组内容是围绕什么组织的”。
第二类，因为害怕用错，干脆一律用div。这会让页面失去结构化信息。最稳的中庸之道是：当你只想给内容加一层样式容器、不想给任何语义时，用div；当你明确知道这一块内容是一个主题分组时，用section；当你明确知道这一块可以独立成篇时，用article。
顺带一提，<section>里最好有标题。规范原文用了“typically with a heading”这个表述，意思是“通常有标题”。一个没有标题的section虽然不违规，但在语义上很尴尬——读屏软件的用户会听到“区域，无标题”，体验非常奇怪。如果你发现自己写的section很难加标题，说明它更像一个div。
3.3 figure和figcaption：给插图、代码块、图表一个正式身份
<figure>标签用来包裹独立的内容单元，常见的有图片、插图、代码块、图表、音频、视频。它和<section>的区别在于，<figure>的内容被移动并不会影响主文档的阅读流畅性——你见过论文里把配图和正文分开排版的吧，就是这个意思。
<figcaption>是<figure>的标题/说明，必须作为<figure>的第一个或最后一个子元素出现。
html复制<figure>
<img src="semantic-html.png" alt="HTML5语义化标签示意图">
<figcaption>图1 HTML5语义化标签在页面中的整体布局</figcaption>
</figure>
关于<figure>有一个很实用但容易被忽略的技巧：如果你用<figure>包一张图片，并且图片下方配了图注，那就不需要在<figcaption>里重复一遍“这是一张关于XXX的图片”——alt属性和<figcaption>各司其职，alt服务于无法看到图片的人，figcaption服务于所有需要在上下文中理解图片含义的人。
在开发实际项目时，<figure>非常适合用来包裹统计图表、广告位（前提是广告作为独立的补充内容）、代码示例块。你不需要为每个<figure>都写figcaption，但建议写上，因为它在语义上相当于“图表的标题”，能显著提升内容的可读性。
4. 那些好用但容易被忽略的细节型语义标签
4.1 mark：高亮不是样式，而是语义
<mark>标签用于标记“与用户当前行为相关”的文本。最典型的场景是搜索结果页里，匹配到的关键词高亮显示。它和用<span style="background-color: yellow">高亮的本质区别在于，<mark>表达的是“这段文字值得特别关注”这个语义，而不是“这段文字应该长成黄色”。
举两个实际的例子：
搜索场景：
html复制<p>在 <mark>HTML5</mark> 中，新增了大量<mark>语义化</mark>标签，这些标签让页面结构更加清晰。</p>
引文中的重点强调：
html复制<blockquote>
“优秀的代码本身就是最好的文档 —— <mark>语义化</mark>让文档更接近这句话。”
</blockquote>
要注意的是，<mark>和<strong>有本质区别：<strong>表示内容“重要性”高，<mark>表示内容“相关性”强。一篇文章中被<strong>强调的内容，通常这篇文档的核心观点会比被<mark>标记的内容更重要；而<mark>标记的内容可能是用户从外部搜索词带入的、或者是文档中希望读者特别注意的一段引用，它们并不一定是全文中最重要的句子。
4.2 time：让时间具有机器可读性
<time>标签用来包装具体的时间值，并通过datetime属性提供机器可读的格式。这个标签对搜索引擎和浏览器扩展程序非常友好——它们能直接提取出结构化时间数据，而不是在一堆文本里绞尽脑汁地判断“昨天下午3点”到底是哪一天。
html复制<p>博客更新于 <time datetime="2025-02-14">2025年2月14日</time></p>
<p>本场促销活动持续到 <time datetime="2025-03-01T23:59">3月1日晚上</time></p>
datetime的格式遵循ISO 8601标准，支持日期（2025-02-14）、时间（2025-02-14T08:30:00）、日期加时区偏移等。
一个常见问题是：<time>能不能用来包装“模糊时间”，比如“三年前”？规范要求<time>的datetime属性必须是一个合法的机器可读时间，所以“三年前”不能直接用<time>包装。你可以把datetime写成一个具体日期，文本写成“三年前”，但这种情况下两者会有不一致的风险，我一般建议宁可不用<time>，也别硬造数据。
4.3 progress与meter：把“过程”和“度量”区分清楚
<progress>标签表示任务的完成进度，比如下载进度、表单填写进度、网络检测进度。它有两个属性：max（总量，默认值为1）和value（当前值）。
html复制<progress value="60" max="100">60%</progress>
<meter>标签则表示一个已知范围内的度量值，比如磁盘使用量、评分、投票数。它有min、max、low、high、optimum、value等属性。
html复制<meter value="0.7" min="0" max="1" low="0.3" high="0.8" optimum="0.5">70%</meter>
两者的区别很微妙但重要：progress适用于“正在进行、还可能变化”的场景，比如文件传输过程中进度从0%走到100%；meter适用于“已经确定、用于衡量”的场景，比如当前服务器负载为70%。如果你写的进度条是要在后台定时刷新的，用progress合理；如果是展示一个静态的比例值，应该用meter。
我自己在写网页端网络检测工具时，就用<progress>展示测速进度，用<meter>展示当前带宽占用率，这样读屏软件能准确播报“上传进度，当前百分之四十五”而不是“度量器，当前值七十”。这个细节虽然不是功能性的刚需，但对无障碍体验的改善非常实在。
4.4 details与summary：零JavaScript的可展开组件
<details>和<summary>是HTML5提供的原生可折叠内容组件。<details>代表可展开区域，<summary>代表该区域的摘要标题。点击<summary>区域，就能控制<details>内容的展开收起，全程不需要写一行JavaScript。
html复制<details>
<summary>什么是HTML5语义化标签</summary>
<p>HTML5语义化标签是通过标签名称本身传递内容含义的HTML元素，如header、nav、main等。</p>
</details>
默认状态下<details>是收起的。如果想默认展开，添加open属性即可：
html复制<details open>
<summary>系统要求</summary>
<p>建议使用Chrome 80以上版本访问本页面。</p>
</details>
<details>在移动端和桌面端的浏览器支持都已经非常完善，利用它你可以方便地实现“FAQ折叠区”“代码示例折叠区”“阅读更多”等交互，比依赖JavaScript库要轻量得多。不过需要注意，<summary>在默认状态下自带一个三角形图标，改样式的成本比普通元素高一些，如果项目对UI细节要求很高，可能需要用list-style: none等属性配合自定义图标。
除了上面这几个标签，还有<address>（联系信息）、<dialog>（对话框）、<output>（计算结果）等语义化标签，它们用的场景更专一。等你对header、nav、article这些主力标签熟练了，再逐个补充也不迟。
5. 实战改造：把一份圣诞贺卡页面从“div堆砌”改成语义化结构
5.1 “原生”写法的痛点
来一个具体场景。假设你要做一个HTML5圣诞贺卡页面，内容包含：页面抬头、横幅、祝福语列表、一张圣诞配图、一个音乐播放按钮、一个“查看祝福语”的折叠区、页脚版权。很多人的第一版可能是这样：
html复制<div class="page">
<div class="top">
<h1>圣诞快乐</h1>
<audio controls src="jingle-bells.mp3"></audio>
</div>
<div class="banner">
<p>圣诞祝福语</p>
<div class="msg-list">
<div class="msg">愿你圣诞平安喜乐</div>
<div class="msg">愿你新年万事顺遂</div>
</div>
<a href="#">查看全部祝福</a>
</div>
<div class="pic-block">
<img src="xmas-tree.png" alt="圣诞树" />
<div class="pic-desc">图：圣诞树装饰</div>
</div>
<div class="footer">© 2025 圣诞贺卡</div>
</div>
在这个版本中，每个区块的职责完全靠class名来传达，读屏软件无法确定“音乐播放器”在哪个区块，SEO优化也无从下手。页面结构没有“骨架”，搜索引擎只能把所有div都当作普通容器，无法提取到“这是一个圣诞祝福卡片”的主题信息。
5.2 语义化改造，一步步替换
第一步，把页面级别的容器换成<body>内的语义结构。用<header>包起页面抬头和横幅，用<main>包起祝福语和图片，用<footer>包起版权。
html复制<body>
<header class="hero">
<h1>圣诞快乐</h1>
<audio controls src="jingle-bells.mp3"></audio>
</header>
<main>
<section aria-labelledby="blessing-title">
<h2 id="blessing-title">圣诞祝福语</h2>
<ul class="msg-list">
<li class="msg">愿你圣诞平安喜乐</li>
<li class="msg">愿你新年万事顺遂</li>
</ul>
<p><a href="#">查看全部祝福</a></p>
</section>
<figure>
<img src="xmas-tree.png" alt="圣诞树" />
<figcaption>图：圣诞树装饰</figcaption>
</figure>
</main>
<footer>
<p>© 2025 圣诞贺卡</p>
</footer>
</body>
第二步，把内部小元素也“语义化”。祝福语列表从<div class="msg-list">改为<ul>，这本身也是语义化的一部分——列表内容就应该用列表标签。接着加入<time>标记祝福发布日期，用<mark>标记当前年份相关的关键词，用<details>/<summary>实现“查看全部祝福”的折叠交互，不再需要额外写JavaScript。
html复制<main>
<section aria-labelledby="blessing-title">
<h2 id="blessing-title">圣诞祝福语</h2>
<ul class="msg-list">
<li class="msg">
<mark>2025</mark>年圣诞快乐：愿你平安喜乐
<time datetime="2025-12-25">12月25日</time>
</li>
<li class="msg">
新年万事顺遂
<time datetime="2026-01-01">1月1日</time>
</li>
</ul>
<details>
<summary>查看全部祝福</summary>
<p>这里列出所有祝福语，一共30条。</p>
</details>
</section>
<figure>
<img src="xmas-tree.png" alt="圣诞树" />
<figcaption>图：圣诞树装饰</figcaption>
</figure>
</main>
第三步，检查标题层级。整个页面只有一个<h1>（在<header>里），main区域从<h2>开始，读屏软件用户能正确理解“h1 => h2”的层级线索。这一点非常关键，在旧版本中到处都是div，标题层级完全失控；语义化改造后，标题层级自然成了文档大纲的一部分。
5.3 改造后的效果对比
以这个圣诞贺卡页面为例，改造前后有几个直观区别：
- 搜索引擎可以从
<main>直接抓住页面核心内容，而不是在多个div中盲目猜测。 - 读屏软件用户可以通过快捷键直接跳过
<header>，直达<main>正文，体验提升明显。 - 视觉上没有任何变化（样式的结构写法和div一致），但代码的可维护性大幅提高。
- 折叠祝福语的功能是用
<details>/<summary>实现的，比原来引入jQuery的“点击展开”方案轻了无数倍。
这个例子说明了一个重要的开发理念：语义化改造不需要推翻重写，也不需要改变视觉样式，只需要把每一层“装东西的盒子”换成“能说明自己职责的盒子”。改完之后代码不变量减少，但信息量成倍增加。
6. 浏览器兼容那些事：老浏览器、测试工具和规避方案
6.1 现代浏览器的支持现状与老浏览器的坑
HTML5语义化标签在2025年这个时间点，对现代浏览器（Chrome、Firefox、Edge、Safari的当前主流版本）来说支持度已经非常完善，可以说是“开箱即用”。但仍有两个历史遗留问题值得注意。
第一个是IE浏览器。IE8及更早版本完全不认识HTML5新标签，会把<header>、<main>、<article>等都当作未知内联元素，导致布局错乱。IE9部分支持，但对main元素的支持依旧不完整——最典型的症状是<main>在IE9下不会被当作块级元素渲染，因为IE9不知道它是什么。
第二个问题关于<video>标签和HTML5播放器的浏览器支持。注意这里的“支持”和语义化标签的“支持”不是一回事。语义化标签的问题是“标签是否存在、是否被正确识别”，而播放器的支持问题主要是“编码格式是否被支持”。比如Safari对WebM格式支持不佳，而旧版Firefox对H.264 MP4支持有限。这意味着你在页面里写<video src="video.mp4"></video>，你在不同浏览器上看到的可能是“能播”“不能播”“只有声音没画面”等多种结局。实际项目中通常需要提供多个格式源：
html复制<video controls>
<source src="video.webm" type="video/webm">
<source src="video.mp4" type="video/mp4">
你的浏览器不支持HTML5视频标签。
</video>
这个兼容性习惯和语义化标签的“降级处理”思路一脉相承：不要指望所有用户的环境都按你的预期工作，提前准备替代方案。
6.2 老浏览器的折中方案：html5shiv与现代工具链
如果项目必须兼容IE8及以下版本，最常用的措施是引入html5shiv（也叫html5shim）。它是一个极小的JavaScript片段，通过document.createElement的方式，提前声明这些新标签，让旧版IE能够正确识别并对它们应用CSS样式。
html复制<!--[if lt IE9]>
<script src="https://cdn.jsdelivr.net/npm/html5shiv@3.7.3/dist/html5shiv.min.js"></script>
<![endif]-->
同时，还需要在CSS中为这些新标签显式声明display: block，因为IE8在没有被shiv识别之前，默认把它们当内联元素：
css复制header, nav, main, aside, article, section, footer, figure, figcaption {
display: block;
}
在工程化项目中，上面的工作其实已经基本被自动化的打包工具替代了。像PostCSS的插件、Babel的polyfill策略，都会自动处理旧浏览器兼容问题。但了解html5shiv的原理仍然有意义——它揭示了语义化标签在旧浏览器下的本质是“自定义元素”，浏览器不认识它们，代码层面就必须做“启蒙教育”。
6.3 用W3C校验器检查页面结构，比想象中更重要
语义化标签用得对不对，不能只靠肉眼判断，最靠谱的方式是使用W3C官方的HTML校验工具（Nu Html Checker）。把页面地址或HTML代码粘贴进去，它会自动报告标签嵌套错误、遗漏属性、标题层级跳级等问题。
我在实际项目里发现，校验器最喜欢报的几个语义化相关错误包括：
<main>出现多次，或者嵌套在其他标签内部。<section>缺少标题。<figcaption>不是<figure>的第一个或最后一个子元素。<time>的datetime属性格式不合法。<ul>的直接子节点不是<li>。
这些错误在代码评审中往往不容易发现，因为浏览器不会因这些错误报错，页面照样渲染，但它们会让语义化标签的努力大打折扣。养成写完代码跑一遍校验器的习惯，比记一堆规范条文高效得多。这也是我目前维持页面结构质量最依赖的工具。
还有一个开发中的小技巧：在Chrome DevTools的Elements面板里，你可以看到浏览器对每个标签的“角色（role）”。比如<header>默认的role是banner，<main>的role是main，<nav>的role是navigation。如果你看到标签对应的role和预期一致，说明语义化生效了；如果看到某个标签的role是generic或空白，说明它没有被正确识别，需要检查兼容性或嵌套关系。
写在最后：语义化不是教条，而是一种思维方式
开发项目这些年，我最大的感受是：语义化标签不是“必须遵守的规范”，而是帮助你思考页面结构的一种工具。当你习惯用header、nav、main、article、section、aside、footer这些词去组织页面时，你会不自觉地开始问自己：这个区块到底承担什么职责？内容之间是什么关系？哪些是独立的、哪些是分组的、哪些是补充的？这种“内容驱动结构”的思考方式，远比死记硬背标签含义更有价值。
在团队协作中，语义化标签也能减少很多不必要的沟通。新人看到<article>就能确定这是独立内容，看到<aside>就知道是补充信息，不需要逐行翻看代码。如果你维护过那种满是<div>的历史项目，就会明白这种“不用解释就能懂”有多珍贵。
下一步如果你想把这条路走得更远，可以尝试结合ARIA（Accessible Rich Internet Applications）规范，给复杂组件（比如手风琴、标签页、弹窗）补充角色和状态信息，这会让你对“语义化”的理解更进一步。希望这篇课程对你的HTML5语义化标签学习之旅有所帮助。