HTML5语义化标签实战指南：告别div堆砌，理清页面结构

一次接手某内部项目时，打开首屏 HTML 我的头就开始隐隐发胀：外层是 div.page，中间 div.content，再往里 div.list-item、div.card、div.footer-info……每个 div 都戴着不同的 class 面具，见不到一个语义标签。功能确实没什么毛病，可当我想快速定位页面里“主要内容区”在哪时，只能靠 class 名挨个猜，猜错了再顺着 CSS 往回找，效率低得很。

HTML5 的语义化标签推出这么多年，大量项目里 div 依然是最忙的标签。不是不能用，而是用错了地方。这篇文章不谈“语义化很重要”这种空话，我打算直接从一个前端开发者的实际项目视角出发，把页面里的头部、导航、主体、文章、侧栏这些常见区域到底该用哪个标签、为什么该用它、哪些位置必须继续保留 div，一次性说清楚。文章里会带一个完整的重构例子，还有我在实际维护中踩过的坑，适合那些写页面时总觉得“结构别扭”但说不清原因的同学参考。

1. 语义化标签的受益清单：SEO、无障碍与代码可维护性

先说动机。很多人对语义化标签的态度是“别人都在说，我也跟着用一点”，并没有真正搞清楚它到底带来什么价值。这导致的结果就是：文档标题用 header，侧边栏也用 header；文章正文用 div，评论区还是 div。在我看来，语义化标签的第一个受益人不是搜索引擎，不是读屏用户，而是三个月后的你自己。

1.1 机器视角：搜索引擎与爬虫如何“读”页面

搜索引擎爬虫抓取网页之后，会分析 DOM 结构来理解“这个页面讲的是什么”“哪里是核心内容”“导航放在哪个位置”。它并不是只看关键词密度，而是会参考标题层级、段落结构、链接组织方式等信息。语义化标签相当于给爬虫画了一张结构图：这是导航、这是主体、这篇文章可以单独抽出去分发、这个侧栏只是补充信息。

举个例子，同样一段“前端开发入门指南”的正文，放在<article>里，爬虫更容易识别出它是页面的核心内容，在生成搜索结果摘要时也更容易提取到正文开头。放在一堆层层嵌套的<div class="content">里，爬虫也能猜，但猜的成本更高，结果自然就不够精确。所以不要相信“加几个语义标签就能上排名第一”的说法，但也不要怀疑语义化能让页面的内容被更准确地理解。说白了，语义化是给机器指路，不是给机器喂药。

1.2 用户视角：读屏软件与键盘导航的真实体验

视力障碍用户依赖读屏软件浏览页面时，它们会从 HTML 里读出“地标”信息。这就像一个网站的目录或路标系统。比如<nav>是导航区、<main>是主内容区、<aside>是补充信息区。读屏用户可以通过快捷键在这些区域之间跳转，直接进入主要内容，跳过一大段重复导航。

如果页面全是 div，读屏软件就只能从头到尾把整页内容全部朗读一遍，用户每次切换页面都要忍受一长串无意义的导航菜单。这体验有多糟，你可以闭上眼睛找个页面亲自听一遍。语义化标签在这里不是锦上添花，而是刚需。尤其是做面向公共服务、教育、电商这些场景的网站，无障碍合规已经是硬性要求。

1.3 开发者视角：让结构成为可视化目录

如果你维护过一个几百行的页面，你应该有这种体会：一个结构良好的语义化页面，HTML 本身就相当于可视化目录。<header>告诉你这里是页面顶部，<nav>告诉你这是导航，<main>告诉你这里是重点，<article>告诉你这是一篇完整内容，<footer>告诉你这里是底部信息。

这种清晰度直接决定了你的开发效率。调试样式时，你可以直接写main article h2，而不是.main-container .post-wrapper .content-wrapper h2这样又长又脆弱的嵌套选择器。写自动化测试时，语义标签也比 class 名稳定得多——别人顺手改了个类名，你的选择器可能就挂了，但<main>不会因为重构而消失。所以语义化其实是一个前期省心、后期更省心的投资。

2. 逐个拆解：核心语义标签的职责边界与典型场景

明白了为什么之后，就进入最核心的问题：每个标签到底管什么。我平时看代码时发现，很多同学的困惑不是“不知道有这些标签”，而是“不知道它们之间的边界到底在哪”。这节我把常用标签按三类拆开讲，注意每个标签的关键词和典型场景。

2.1 页面骨架四件套：header、footer、main、aside

<header>表示的是“一组引导性或介绍性内容”，可以出现在页面级，也可以出现在 article、section 内部。页面顶部通常用它做横幅区，里面放 logo、站点标题、导航；文章开头用它放标题、作者、发布时间也很合理。一个页面可以有多个 header，但它们各自对应自己所在区块的“头部”，不是全局的。

<footer>表示“区块底部的元信息”，常见内容是版权声明、相关链接、作者信息、联系方式。它同样可以出现在页面级，也可以出现在 article 或 section 内部。比如一篇文章底部放“关于作者”的卡片，用<footer>包一层就非常合适。要注意的是，footer 不一定必须放在页面最底部。

<main>表示页面的核心主体区域，一个页面只能有一个，而且不应该被放到 article、nav、aside 这些标签里面去。它就是用来说明“这页最重要的内容都在这里”。爬虫和读屏软件拿到<main>可以直接锁定正文，不需要挨个 div 找。这也是对比 div 版本时，最立竿见影的一个改进。

<aside>表示与主内容“间接相关”的内容，常见形态是侧边栏、相关推荐、广告位、引文、注释。判断方式很简单：如果把它从主内容里删掉，主内容仍然完整成立，那它就是 aside 的料。注意，侧边栏不一定要放在视觉上的右边，语义上是“补充信息”，跟 CSS 布局无关。

这四件套组合起来，就是绝大多数页面的基础骨架：

<body> <header>站点标识、主导航</header> <main>核心内容</main> <aside>相关推荐、广告</aside> <footer>版权、备案信息</footer> </body>

除此之外，浏览器还会给这些标签默认映射无障碍角色：header 映射 banner、footer 映射 contentinfo、main 映射 main、aside 映射 complementary。这意味着读屏软件天然能识别它们的功能，不需要你额外写角色属性。

2.2 内容组织两兄弟：article 与 section

<article>的定义很有意思：它是一个“可独立分发或复用”的内容单元。什么叫独立分发？就是你可以把它单独拿出来放到别的地方，人家依然看得懂。一篇博文、一条新闻、一个论坛帖子、一条评论、一个产品卡片，都符合这个特征。判断时问自己一个问题：如果我只把这个区块发给朋友，他能否在不看页面其他内容的前提下，理解它讲的是什么？能，就用 article。

<section>表示一个“有主题范围的分区”，强调的是主题上的分组关系，而不是独立性。比如一篇长文里有“背景介绍”“实现方案”“性能对比”三个部分，它们有各自的标题，放在一起才组成完整文章，那就适合用 section 来分。<section>通常建议带一个标题，这个标题能很自然地形成文档的章节感。

两者经常搭配出现：一个 article 内部可以用多个 section 拆分论点；一个页面也可以用多个 article 平铺多条新闻。反过来，不要用 section 去包一组毫无主题的 div，也不要因为某个区域“感觉很重要”就硬给它套上 article。一个没有独立语义的内容套 article，只会让爬虫读到一堆结构错位的“独立内容”。

2.3 容易被忽视的语义小部件：figure、time、mark、blockquote、details

除了页面骨架和内容组织，HTML5 还提供了一批“零件级”的语义标签，它们个头不大，但用对了非常提升语义准确度。

<figure>配合<figcaption>是给插图、代码块、表格、图表这类“被主体内容引用”的内容做包裹的。图注 figcaption 相当于图的解释文字，这种“图与注释的关联关系”是普通 div + p 表达不了的。

<time>用来标记时间，关键是 datetime 属性。如果你只写“昨天”，机器是无法知道具体日期的；写成<time datetime="2025-07-29">昨天</time>，机器和人都能读懂。在排序、日历类应用里，这个标签能省去很多猜测。

<mark>表示“因为上下文原因需要被标注出来的文字”，比如搜索结果里的关键词高亮、引文中被你特别标出的话。很多人会把 mark 和 strong、em 混在一起，其实它们是不同的维度：strong 表示重要性，em 表示语气强调，mark 表示上下文相关性。

<blockquote>负责长引文，引文来源可以用cite属性或<cite>标签标记；<details>配合<summary>做一个默认隐藏、点击展开的折叠区域，用来放“进阶说明”“FAQ 答案”这类次要内容很顺手。

这些标签单个看起来不起眼，但一个页面上语义信息的密度，往往就是靠这些细节攒起来的。

3. 语义化不等于消灭 div：什么时候必须继续用 div

每次讲语义化，我都担心读者走向另一个极端：把页面上所有 div 都替换成语义标签，连一个 10 像素的间距容器都要找一个“表意词”来套。这个方向与“滥用 div”同样有害。div 本身没有任何语义，但它的价值恰恰在于“没有语义”。

3.1 div 的合法用途之一：纯视觉容器与 CSS 承载点

布局里经常有一些纯粹为视觉而存在的容器：一条分割线、一个圆角卡片的外壳、一个 flex 网格里包裹整行的 wrapper。它们不承载任何“内容含义”，只是在 CSS 层面承担间距、背景、排列方式。这种情况下，div 是最诚实的选择。你要是硬找一个语义标签，反而会让爬虫和读屏软件产生误解。

举例来说，一个商品卡片整体用<article>描述商品信息没问题，但卡片里的图片和文字之间需要一个 flex 容器来控制排列方向，这个容器就该用<div>。它不表达“这是一个独立内容”，它只是排版的工具人。

3.2 div 的合法用途之二：JavaScript 钩子绑定点

前端框架兴起之后，页面里大量 div 是作为组件的根节点存在的。比如 Vue 或 React 组件里，一个组件的模板最外层常见<div class="user-card">。这个 div 的功能是给组件提供一个挂载点，让 class 和事件绑定有一个稳定的宿主。这就是很典型的“没有语义含义，但确实需要存在”的场景。

同样，一些自定义交互控件——比如日期选择器、拖拽排序列表——它们需要包裹层来承载定位、事件监听、状态 class，这些包裹层语义本身并不重要，用 div 是合理选择。

3.3 用语义化之前，先设计结构层级

我在 review 别人代码时发现，很多滥用语义的情况根因是“没有先设计结构，直接边写边套标签”。结果是 header 里套 header，nav 里再放 nav，整个结构跟套娃一样。

正确的做法是：先画出页面结构草图，明确每个区块的职责，再决定标签。一个页面从上到下通常是：页面头部→主导航→主体区（可含文章、侧栏）→页面底部。主体区内部再细化：文章→章节→段落；侧栏→小组件。这张草图画完了，每个区域对应哪个标签基本就清楚了，div 的用武之地反而很明确——没有职责可言的区块。

所以我的建议是：不要把“语义化”当成一个需要完成的指标，而是把它当成一个始终在问自己的问题——“这个区域到底在表达什么？”。能回答就用语义标签，回答不了就老老实实用 div。语义化是帮人理解结构，不是为了证明你不用 div。

4. 面对一个模块迅速选标签：我的三步提问法

在实际开发中，我们大半时间不是在设计整站骨架，而是在处理一个个具体模块：一个评论区，一个商品列表，一个页脚链接组。这时候每次都要翻文档显然不现实。我总结了一个自己的三步提问法，按顺序走，基本能在十秒内决定该用哪个标签。

4.1 三步提问：从独立内容到兜底方案

第一步，问自己：这个模块如果单独拿出来，是否依然有意义？比如一条评论、一篇博客、一款商品的完整信息，单独拿出来别人也能理解，那它应该进入<article>。

第二步，如果它不能单独成立，那么它是否是一个有清晰主题的区块，并且内部有自己的一组信息？比如文章里的“实现原理”这一节、页面的“评论区列表”区域，它们和周围内容有边界，适合用<section>。注意 section 应该尽量带标题，形式上是“章节的感觉”。

第三步，思考它和页面主内容的关系。如果它是主内容的铺陈、补充、延伸，比如相关文章、广告、侧栏的个人介绍，那用<aside>更合适。如果它不是主内容的组成部分，删掉也不影响页面完整度，aside 就很贴合。

走完这三步还没有落点，再看它属于几种“角色型”标签之一吗？导航栏用<nav>，页脚版权区用<footer>，页面核心主内容用<main>，作者联系信息用<address>。再不行，就大方使用<div>——因为那些没有被语义识别需求的部分，本来就该由 div 来兜底。

4.2 常用模块的速查对照表

为了方便日常快速参考，我整理了一张模块对照表，你完全可以把它存成笔记：

这张表不是为了让你机械对照，而是帮你建立一个直觉：每个模块先想语义，再想视觉；先想内容独立性，再想主题分组；真正没有语义的排版层，才轮到 div 出场。

5. 实战重构：把一个博客文章页从 div 海改成语义化结构

理论讲再多，不如看一次真实改动。下面我拿一个典型的博客文章页做例子，先展示原始版本的“div 全家桶”，再展示语义化版本，并且逐条说明每一步的改动理由。这是我实际协助某项目重构时用到的思路，比较有代表性。

5.1 原始版本：一个典型的“div 全家桶”

原始页面结构大概是这样的：

<div class="page"> <div class="header"> <div class="logo"> <img src="logo.png" alt="站点标识"> <span>我的博客</span> </div> <div class="navbar"> <a href="/">首页</a> <a href="/archive">归档</a> <a href="/about">关于</a> </div> </div> <div class="main"> <div class="post"> <div class="post-title"> <h1>手写一个轻量级前端项目脚手架</h1> </div> <div class="post-meta"> <span>发布于 昨天</span> <span>分类：前端工程化</span> </div> <div class="post-content"> <div class="section-1"> <h2>为什么需要自己的脚手架</h2> <p>……</p> </div> <div class="section-2"> <h2>核心设计思路</h2> <p>……</p> </div> </div> </div> <div class="sidebar"> <div class="widget"> <h2>相关阅读</h2> <div class="widget-list"> <div class="widget-item"><a href="#">前端项目目录结构设计</a></div> <div class="widget-item"><a href="#">构建工具的底层原理</a></div> </div> </div> </div> </div> <div class="footer"> <div class="copyright">© 2025 我的博客</div> </div> </div>

你能看到，整篇 HTML 除了 class 名之外，识别不出任何“区块身份”。想了解这个页面的重点在哪，得靠人脑去猜.main、.post、.post-content之间的从属关系。这种结构在维护时非常容易出错，尤其是当后手接手的人对业务不熟的时候。

5.2 语义化版本：结构对比与每处改动理由

改完之后的语义化版本长这样：

<body> <header> <p class="logo"> <img src="logo.png" alt="站点标识"> 我的博客 </p> <nav aria-label="主导航"> <ul> <li><a href="/">首页</a></li> <li><a href="/archive">归档</a></li> <li><a href="/about">关于</a></li> </ul> </nav> </header> <main> <article> <h1>手写一个轻量级前端项目脚手架</h1> <p class="post-meta"> 发布于 <time datetime="2025-07-29">7月29日</time> · 分类：前端工程化 </p> <section aria-labelledby="section-why"> <h2 id="section-why">为什么需要自己的脚手架</h2> <p>……</p> </section> <section aria-labelledby="section-design"> <h2 id="section-design">核心设计思路</h2> <p>……</p> </section> </article> <aside aria-label="相关阅读"> <h2>相关阅读</h2> <ul> <li><a href="#">前端项目目录结构设计</a></li> <li><a href="#">构建工具的底层原理</a></li> </ul> </aside> </main> <footer> <p>© 2025 我的博客</p> </footer> </body>

逐条看关键改动：

第一，最外层.header改成<header>包裹整个站点头部，navbar改成语义上更准确的<nav>，并给aria-label="主导航"标明这一组导航在整站中的角色。导航内部用<ul>和<li>组织链接列表，而不是一堆<div><a></a></div>。这样读屏用户能直接知道这里共有多少个导航项，爬虫也能清楚识别导航结构。

第二，.main改成<main>，直接声明“本页核心内容在这里”，而且只保留这一个。这一步对无障碍和搜索理解影响最大。如果页面同时有多个 main，辅助技术会无所适从，规范也明确只允许一个 main。

第三，post改成<article>。因为这篇博客正文本身就是可以单独分发的完整内容——别人复制过去照样成立。标题 h1 直接作为文章标题，省掉了div.post-title这一层纯包装。发布时间用<time datetime="2025-07-29">标记，机器可读。

第四，文章内部两个区块改成<section>，并且给每个 section 配上可见的 h2 标题，因为没有标题的 section 在可访问性树里经常被忽略。我还加上了aria-labelledby指向标题 id，让辅助技术能把这个 region 当作一个有名字的独立区块来播报。

第五，侧栏改成<aside>，因为它属于“相关阅读”，和主内容只有间接关联，删掉不影响文章完整性。相关阅读列表也用了<ul>+<li>，而不是 div 套 div。

第六，底部的版权信息放进<footer>，这是整份文档的收尾元信息。如果你项目里还有“关于作者”这类文章级底部信息，完全也可以在 article 内部再放一个 footer，只要它描述的是当前区块的底部信息就行。

5.3 重构后带来的实际变化

这些改动带来的反馈不是玄学。重构之后，调试时我用main article h2就能直接命中标题样式，不再需要.main .post .post-content h2那串又长又脆弱的选择器。

无障碍审核时，工具列出的地标列表变成了“banner、main、complementary、contentinfo”，层次分明。用键盘配合读屏软件操作时，用户可以直接从 banner 跳到 main，跳过三次重复出现的导航链接。对内容型网站来说，这种体验改进是肉眼可见的。

还有个容易被忽略的好处是自动化测试。我后来写端到端测试时，选择器直接写main article h1，不依赖任何 class 名。哪怕项目里某个类名被重命名了，测试依然稳定，因为语义标签是文档结构的一部分，不会被轻易重构掉。

6. 语义化避坑清单：这些问题踩过才记得牢

这一节写的是我在实际项目里踩过、也帮别人 review 时经常见到的坑。每个看起不起眼，但积累多了，整页语义化就形同虚设。

6.1 article 里嵌套 section 没问题，反过来要小心

<article>里可以有多个<section>，这是一篇长文章常见的结构；但当你在<section>里再嵌套多个<article>，就要多想一层：这些 article 是不是真的可以独立？如果你的 section 表示“产品列表”，里面每个产品确实可以单独理解，那每个产品用article很合适。但如果 section 里的 “article” 只是一些零散段落，它们根本不能独立，那就别套。

我见过最夸张的写法是<section><div><section><div><section>这种连环套。这跟 div 嵌套一样令人抓狂，因为它并没有增加任何语义价值。规则很简单：只有在内容语义上确实需要分层时，才嵌套语义标签。

6.2 一个页面只允许有一个 main，这句话不能打折

<main>代表页面的核心主体，规范明确一个文档只能有一个。我在部分项目里见过“首屏一个 main，详情弹窗又写一个 main”的情况。这会让辅助技术无法判断到底哪个才是真正的主体。

如果需要做一个全屏弹窗或者模态框，请让弹窗内容保持普通元素身份，不要使用 main 强调它。弹窗本身的语义可以由role="dialog"或aria-modal来表达，而不是抢 main 的位置。

6.3 header 不是只能出现在页面顶部

很多人习惯把header理解成“顶部横幅”，实际它表示的是“一组引导性内容”，所以它也完全适合出现在<article>、<section>、<aside>内部。比如一篇文章开头放作者、日期、标签的一组信息，用<header>包裹是合理的，它不是页面级头部，而是这篇文章的头部。

反过来，不要因为你视觉上把它放在页面底部，就拒绝使用<footer>。一篇文章末尾的“作者卡片”用 footer 是合适的，因为它就是这篇文章区块的底部元信息。

6.4 hgroup 已被移除，别再用老理写组合标题

HTML5 早期规范里有<hgroup>，用来把主标题和副标题组合在一起，但后来的规范已经移除了它。现在你用它，浏览器虽然能渲染，但它已经不具备规范的语义含义，还会让标题结构变得混乱。

目前推荐的做法是用<p>放副标题，或者直接用一个<header>包住标题组合。比如：

<header> <h1>前端工程化实践</h1> <p>从项目初始化到持续交付</p> </header>

这样既保留了组合关系，又不破坏标题结构。如果你还在项目里用 hgroup，是时候清理掉了。

6.5 address 只负责联系信息，不是地址栏的通用品

<address>表示的是文章作者或相关组织的联系方式，比如邮箱、联系电话、公司地址，而不是页面上随便哪个“地址栏”或“收货地址”。很多同学看到地名就套<address>，这其实偏离了它的语义定义。

如果你在写一个快递收货地址表单，请用普通标签加合适的 aria 标注，而不是<address>。真正的 address 场景是页脚里写“联系站长：feedback@example.com”，这时候用它就非常合适。它是给“组织/作者联系信息”准备的，不是给所有“地址”词汇准备的。

6.6 section 的可访问名称：没标题的 section 很可能被忽略

<section>在无障碍树里默认映射为region角色，但这个region只有在它有“可访问名称”时才会被读屏软件识别为地标。可访问名称的来源可以是可见的标题（h2 等），也可以是 aria-label。

换句话说，如果你写一个<section>，里面却没有标题，也没有加 aria-label，读屏用户很可能根本感知不到它是一个独立区块。这也是为什么我在实战案例里给每个 section 都加可见标题，或至少用 aria-label 标明用途。不加名字的 section，跟一个普通 div 在无障碍体验上没有本质区别。

6.7 details 与 summary 的交互：好用，但别承载关键信息

<details>和<summary>能在不写 JavaScript 的情况下做出展开收起效果，确实很香。但它有一个潜在问题：折叠区里的内容默认是隐藏的，部分辅助技术对它内部的播报支持也不统一。

所以我的建议是：把 details 用于“补充说明”“常见问题”“进阶阅读”这类非关键信息。如果一个信息是整个流程里用户必须看到的，那就直接展示，别收进折叠区。折起来谁也看不见的内容，等于不存在。

说到底，语义化本身不是目的，它只是为了让人和机器都能更好地理解页面。这套标签体系并不难，难的是每次写结构时停下来想一下“我在表达什么”。我自己的习惯是：写 HTML 之前，先在草稿纸上把每个区块画出来，标上它的职责，再动手选标签。这样写出来的页面，结构清晰，维护省心，也不会被“滥用 div”或“滥用语义标签”两种极端拉扯。希望这份从实际项目里总结出来的经验，能让你下次写结构时更有底气。