★ FEATURED ARTICLE 1. 别急着写代码先说说我们为什么会把 div 用成习惯做前端的谁没被代码审查说过几句“div 套 div套娃呢”——我最早写页面的时候也是这样脑海里只有三个标签div、span、p剩下的全靠 class 命名硬撑。结果页面结构看起来就像一盘散沙自己隔两周再看都得靠注释回忆“这块是啥来着”更别提团队协作时别人接手代码时的崩溃表情。div 本身不是坏东西它是一个无语义的块级容器它的设计初衷是“当你实在找不到合适的语义标签时用我兜底”。但现实是我们把它当成了默认选项本该用 header、nav、article、footer 表达的页面骨架全被“div class”替代了。这带来什么问题呢最直接的是可读性差、可维护性低更深层的则是 SEO 不友好、无障碍支持缺失。HTML5 推出语义化标签体系已经很多年了从 IE9 时代开始就有 polyfill 方案到如今所有现代浏览器原生支持已经没有任何技术理由拒绝它们。这篇文章我打算从使用场景出发把HTML5 语义化标签的选用逻辑、实际写法、常见误区和排查思路一次讲透让你看完之后能直接上手改造自己的项目而不是停留在“知道有这么回事”的层面。这篇文章适合谁看呢如果你已经能熟练写 div 布局但不太清楚 header、main、section、article 这些标签到底该怎么分配或者你负责的项目结构混乱想借着语义化重构的机会把代码质量提上去又或者你写了不少页面但总被评审说“语义不对”——那这篇就是给你准备的。2. 语义化的底层逻辑为什么浏览器和搜索引擎需要“看得懂”你的页面2.1 div 表达不了的东西恰恰是最重要的信息我们得先搞清楚一个概念HTML 标签本身是带“含义”的。浏览器、搜索引擎爬虫、屏幕阅读器它们读你的页面时并不像人类看渲染效果那样“一眼就知道这块是导航那块是正文”。它们靠的是标签名属性来理解内容结构。比如div classnav和nav渲染出来的视觉效果可能一模一样但在机器眼里有天壤之别。前者就是“一个容器”具体是什么内容得靠 class 名称去猜后者则明确告诉程序“这里面是导航区域链接集合。”这就是语义化标签存在的底层价值——把视觉结构背后的逻辑结构显式表达出来。想想搜索引擎的处境它每天要爬取海量页面为了判断一个页面的内容质量、主题相关性它需要快速定位页面主内容在哪里、侧栏在哪里、导航有哪些、文章正文从哪个标签开始。如果你的页面全是裸 div爬虫就必须靠算法猜测。猜错的结果是什么轻则关键词权重分配偏差重则页面摘要取错内容。这就是为什么业内一直强调“语义化是 SEO 的地基”。2.2 无障碍不是“加分项”而是“必答题”这块我想多说几句因为很多人对无障碍Accessibility简称 a11y的认识停留在“给图片加个 alt”的程度。实际上对于依赖屏幕阅读器的视障用户来说你的页面是一串线性朗读的文本流。他们需要通过不同的标签来构建心理模型按 h1 跳转到标题、按 nav 跳过导航、按 article 直接读正文。如果这些结构全部由 div 构成读屏软件的唯一策略就是把所有内容从头到尾念一遍——信息获取效率极低。我记得某团队做过一次无障碍审查测试拿了一个纯 div 布局的老项目用读屏软件操作结果是用户想找页面主要内容需要在几百个“容器容器容器”的朗读声中摸索十几秒。这不是夸大其词div 在无障碍树里默认是不产生任何角色的只有显式指定 ARIA 角色才能弥补但绝大多数项目根本没做这一步。所以我在项目规范里通常写得很直白语义化标签是无障碍支持的最低成本实现路径比任何 ARIA 补丁都自然。2.3 语义化标签的“信息量”比你想的大来看一份简单的对比表更直观地感受语义标签带来的额外信息写法机器理解维护者理解div classheader一个普通容器语义未知需要阅读 class 名称header页面级或区块级的头部区域直接知道是头部div classnav普通容器内部可能是任意内容需要结合上下文nav导航链接集合直接知道是导航div classfooter普通容器语义未知需要阅读 class 名称footer底部信息区版权、联系方式等直接知道是底部表格想表达的核心是class 名到底只是“给人看的备注”而标签名是“给机器和人共同阅读的结构契约”。两者差着整整一个维度。3. 语义化标签全景拆解每个标签该用在哪、怎么用3.1 页面骨架的“四大金刚”header、footer、main、nav先从最顶层的结构标签说起。header代表的是“介绍性内容的容器”它可以是页面级的也可以是某个区块内部的。比如文章开头的一组导语、logo 区域、作者信息都可以放 header。注意一个容易混淆的点header并不等同于“页面顶部那条栏”——一个页面里可以有多个 header每个 section 或 article 里都能有自己的 header。footer同理它表示“末尾区域”里面通常放版权声明、联系方式、相关链接。HTML5 标准对 footer 的定位是“包含关于它所在区块的信息”所以不是只有页面最底部的栏才能叫 footer文章末尾的“标签列表、作者简介、上一篇下一篇”也适合用 footer。main是一个页面里只能出现一次的元素标识文档的主内容区域。它有一个很实际的作用帮助屏幕阅读器用户直接跳到主体内容绕过导航和侧栏。main 里面不能再嵌套另一个 main这个限制要记清楚。nav专门用来包裹“主要导航链接集合”。但别把页面里所有链接都塞进 nav——比如文章正文里的某个超链接那是正文内容的一部分不属于导航。判断标准简单粗暴这组链接是否承担“在站点/模块内跳转”的核心功能是的话用 nav不是就别用。3.2 内容区的两大主角article 与 section这两个标签的区分是整个语义化体系里最容易出错的地方。先看定义article表示“文档、页面、应用或站点中一个自包含的独立内容组合”。换句话说article 里的内容应当是完整独立的把它单独拿出来它依然有明确意义。典型场景一篇博客文章、一条论坛帖子、一个商品卡片、一条评论。section表示“文档中一个独立的、通常包含标题的区块”。它的核心特征是“有主题”通常搭配一个 h1-h6 子标题出现。section 的定位比 article 低一层article 可以由多个 section 组成section 里也可以包含 article。我实际操作时判断这两个标签会用一句话自测“这段内容如果脱离当前页面单独丢到另一个页面里还能不能自圆其说”能就是 article不能只是当前页面的一个分区就用 section。举个例子一个新闻列表页main h1科技新闻/h1 article h2AI 辅助编程工具的最新进展/h2 p正文内容.../p /article article h2移动端框架选型实践/h2 p正文内容.../p /article /main列表里的每篇新闻都完整独立是典型的 article 场景。而如果是一个“产品介绍页”分为“产品功能”和“用户评价”两个模块这两个模块拆出去单独看就不够独立应该用 section。3.3 细粒度语义aside、figure、time、address往下细拆还有一批常用但容易被忽略的语义标签。aside表示与主体内容“间接相关”的内容。侧边栏是典型用法但它也可以用在 article 内部比如一篇文章里的“补充阅读”“术语解释”。关键点是 aside 的内容是辅助性的删掉它不影响正文的完整性。figure配合figcaption用来包裹插图、代码块、图表这类“独立引用的内容”。它的价值在于figure 里的图片、表格不是正文叙事的一部分而是被引用的素材figcaption 则给这个素材提供说明文字。time可以给日期时间标记机器可读格式比如time datetime2025-01-152025年1月15日/time。搜索引擎和读屏软件能够根据 datetime 属性准确识别时间而不是靠猜自然语言字符串。address不是用来写“页面底部通讯地址”的——它表示“附近最近的 article 或 body 的 contact info”。所以文章末尾的“作者邮箱、作者主页”适合放 address网站底部的公司地址其实用 footer 内部普通文本或 address 均可但要理解它的语义是关联最近的 article 而不是全局。3.4 标题体系h1-h6 不是用来调字号的这一节虽然不讲新标签但它是语义化的骨架。很多人把 h1-h6 当“字号选择器”觉得 h1 太大就用 h3 配合 CSS 改大字号——这是大忌。标题标签的本质是定义“文档大纲”heading outline就像一本书的目录。读屏用户可以在标题之间跳转搜索引擎也用标题结构推断主题层级。一个页面的 h1 应当表达页面核心主题h2 是章节h3 是章节内的小节层级要清晰并减少跳级。比如一个新闻详情页h1某地举办开源技术交流大会/h1 h2大会亮点回顾/h2 h3主题演讲环节/h3 h3圆桌论坛环节/h2 // 这里是错误示范h3 之后不能跳回 h2 的层级逻辑里做子项标题层级一旦乱了文档大纲就是一团乱麻。反过来说如果你发现自己为了“看起来更小”而用了低级标题正确的做法是坚持使用匹配层级关系的标题用 CSS 去控制视觉效果。记住这句话HTML 负责结构和意义CSS 负责长相和布局两者别混着来。4. 实操落地从零把一个 div 页面改造成语义化结构4.1 改造前一个典型的“div 套娃”页面假设我们现在手上有一个个人博客首页的静态原型结构大概长这样div classpage div classtop-bar div classlogo我的博客/div div classmenu a href/首页/a a href/archive归档/a a href/about关于/a /div /div div classmain-content div classpost-list div classpost div classpost-title第一篇文章标题/div div classpost-meta发布于 2025-01-10/div div classpost-excerpt摘要内容……/div /div /div div classsidebar div classwidget热门标签/div /div /div div classcopyright版权信息/div /div说实话这个结构本身不算太烂class 命名也算清晰但你直接告诉机器“哪里是导航、哪里是主内容、哪里是侧栏”了吗没有。机器看到的只有一层层无身份的 div。读屏用户不看 CSS 的话根本分不清上下左右的结构关系。4.2 改造后一版可参考的语义化结构来我们把这个结构逐层替换成对应的语义化标签body header div classlogo我的博客/div nav aria-label主导航 a href/首页/a a href/archive归档/a a href/about关于/a /nav /header main section aria-labelledbylatest-posts h1 idlatest-posts最新文章/h1 article h2第一篇文章标题/h2 p 发布时间time datetime2025-01-102025年1月10日/time /p p摘要内容……/p a href/posts/1阅读全文/a /article article h2第二篇文章标题/h2 !-- 结构同上 -- /article /section aside aria-labelledbysidebar-title h2 idsidebar-title侧栏/h2 ul lia href/tags/htmlHTML/a/li lia href/tags/cssCSS/a/li /ul /aside /main footer address联系邮箱devexample.com/address p© 2025 我的博客/p /footer /body对照一下改动点顶部栏 → header明确“这是页面头部区域”。菜单 → nav告诉机器这是一组导航链接。内容主体 → main标记主内容独一份区域。文章列表区 → section article 组合列表本身是一个内容分区每篇文章是一个独立内容单元。文章标题 → h2配合 h1 的“最新文章”形成两层大纲。发布时间 → time[datetime]让时间是机器可读的。侧栏 → aside明确辅助性内容。底部版权 → footer address底部信息语义化。这么一套改下来这个页面的“文档大纲”就清晰了页面标题是“我的博客”第一层章节是“最新文章”每个文章标题是第二层章节侧边栏是独立的辅助区块——机器可以像读目录一样理解你的页面。4.3 头部、导航、面包屑细节里的门道再补充几个常见场景。关于nav一个页面不一定只有一个。站内主菜单一个、页脚链接集合一个都是可以的。用aria-label区分它们的含义比如nav aria-label主导航和nav aria-label页脚导航读屏用户在两个导航之间跳转时就能分辨“这组链接是什么”。面包屑导航要不要用 nav用。而且更规范的写法是在 nav 里配合ol有序列表因为面包屑本质是一个层级路径有序列表能表达“位置顺序”。页面头部还有个常见的细节logo 和站点名称。logo 如果是一张图片用img加alt站点名称如果想把整个站点名称做成链接通常放在 header 里的a包裹的span或p里不必额外套个 h1——除非你确实希望“站点名”出现在文档大纲的顶层。5. 重构中的“语义选择判断器”section 到底该不该出现写代码时我经常被同事问“这个模块到底应该用 section 还是 article还是两个都不用”后来我总结出一套简单的判断流程分享给你这段内容是不是独立的完整单元—是→article否。那么这段内容是不是当前页面主题下的一个“有主题的分区”—是→section否。那么它是不是一个纯粹的样式容器比如为了 flex 布局嵌套而加的包裹层—是→div这套流程能解决八成疑问。特别要提醒的是如果你用 section 的唯一目的是给它加个 CSS 类名做布局那这个 section 就是多余的不如直接用 div。语义化不是“用越多语义标签越好”而是“在合适的层级用合适的标签”。说到这顺带纠正一个流传挺广的误读“section 必须包含标题。”这个说法在 HTML5 之前的旧规范讨论里出现过现行标准里 section 通常应包含标题但你硬套也会出现“为了包含标题而编造一个标题”的尴尬场景。我的建议是能配上标题就配让大纲结构更清晰配不上标题的时候重新审视一下到底是不是该用 div。再聊下“纯样式容器”这个概念。语义化改造不代表不能有 div——flex 布局的包裹层、网格的占位容器、给 JS 做 Hook 的节点这些场景 div 依然是唯一合理选择。语义化的目标不是消灭 div而是消灭“本不该用 div 却用了 div”的情况。5.1 语义化的辅助道具ARIA 什么时候该上ARIAAccessible Rich Internet Applications是一套为无障碍提供额外语义的属性体系。当原生语义标签表达不了需要的含义时ARIA 可以“补刀”。比如一个自定义下拉菜单光是 divclick 事件读屏用户根本不知道这是菜单。这时候需要rolelistbox、aria-expanded等属性来补充。但有一个核心原则能用原生标签解决语义的先用原生标签ARIA 是补救方案不是常规方案。拿导航举例子如果已经用了nav就不需要再写rolenavigation原生标签自带该角色。很多人写语义化重构时第一反应是“把 div 全换成 section同时加一堆 role”这其实是把语义化和 ARIA 混为一谈了。语义化标签是“天生自带角色”ARIA 是“后天强行赋予角色”。后者在复杂组件里是必需的但如果你发现自己的页面到处都需要 ARIA 来补语义往往说明基础标签选错了。6. 我踩过的坑几个典型误用案例与排查要点6.1 把 header 和 nav 理解成了“页面顶栏”我见过不少新手重构页面把“页面顶部那条深色栏”整个换成 header里边又套了一个 nav。看起来没问题但如果这条顶部栏同时包含 logo、搜索框、登录按钮呢这时候 header 是正确的总容器nav 只负责包裹链接集合就好不要把搜索框也塞进 nav——搜索框虽然有交互但它不是“导航链接集合”。真正的坑在另一面有的页面根本没有传统的“顶部栏主导航”而是侧边栏导航或者底部导航。nav 跟视觉位置无关哪怕导航栏出现在视觉上的页面底部照样可以用 nav 包裹。语义标签描述的是“内容性质”不是“长得像什么”。6.2 article 嵌套 article什么时候合法什么时候是滥用article 是可以嵌套 article 的。典型场景是评论列表每条评论是一个 article整个评论区用 section 包裹每条评论下还可以有回复回复又是 article。这看起来叠了好几层但在语义上是合理的每条评论本身就是“一个独立的内容组合”。但如果你只是把一个卡片风格的模块堆到另一个卡片风格模块里互相之间没有“独立内容单元”的关系那就不该嵌套。核心判断还是那句老话独立拆出去是否有完整意义。6.3 标题层级乱跳的排查这个问题的隐蔽性在于浏览器渲染时 h3 和 h2 的默认字号差异不明显肉眼不太看得出来。但文档大纲一旦乱了读者用“按标题跳转”功能时就会像迷失在迷宫一样。排查方法很简单用浏览器的无障碍树查看器比如 Chrome DevTools 的 Accessibility 面板看看页面大纲层级是否连续。常见的跳级场景页面主标题是 h1模块大标题却直接用了 h3没有 h2 过渡或者文章页把每篇文章的标题都写成了 h1。记住一个文档只有一个合理的“根标题”h1它可以是站点名也可以是文章标题看场景其余层级依次为 h2、h3……而不是每个模块都抢 h1。6.4 验证语义化成果的工具清单折腾完了怎么确认自己的语义化改造是真的有效我的常规验证动作是用 W3C Nu HTML 校验器跑一遍看有没有标签嵌套错误。用 Chrome DevTools 的 Accessibility 面板检查页面大纲。用读屏软件实测一下Windows 可以用开源的 NVDAmacOS 自带 VoiceOver听一听页面结构是否清晰。必要时用 Lighthouse 的无障碍审计项跑一次虽然它不是语义化的最终裁判但能发现一些明显的漏网之鱼。这几个步骤做完基本能保证你的页面结构在机器视角下是通的。7. 再往深一层SEO 视角下的语义化收益与边界7.1 爬虫的“抓重点”能力提升搜索引擎从你的页面结构里抽主要内容的逻辑虽然各家不公开但有一点在业内是共识清晰的内容层级和语义标记能有效帮助爬虫识别主内容区域减少噪声干扰。title、h1、h2 这几个要素在搜索引擎确定页面主题时权重相对更高。举个例子两个同样内容的页面一个把文章标题放在 h1 里另一个把它放在 div 里靠 CSS 撑成大字——在搜索引擎眼里前者的主题信号明确得多。这是不是说只要用了语义化标签就能排名飙升当然不是。语义化是“内容被正确理解的必要条件而不是排名靠前的充分条件”。它是基础建设不保证绝对收益但没有它其他 SEO 工作的落地效果会打折扣。语义化标签跟结构化数据如 JSON-LD经常被混为一谈这里澄清一下结构化数据是在 HTML 之外的显式数据描述而语义化标签是 HTML 内部自带的信息层级。两者可以配合使用但职责不同。7.2 维护效率语义化是团队协作的“隐性文档”抛开 SEO 和无障碍我最看重语义化的实际理由之一是团队协作效率。想象你接手一个别人写的页面如果结构是这样的div classwrap div classinner div classcontent div classpost-body你基本只能靠 CSS 选择器和文字内容反推每一层的作用。而如果结构是这样的main section article p正文/p /article /section /main哪怕样式类名再乱你能第一时间看懂层级逻辑这是主内容区里的一个分区分区里有一篇独立文章。语义化标签就像代码注释而且是“永远和内容同步更新、不会过期”的注释。这层收益在项目规模变大后尤其明显。8. 多标签复用规则hgroup、details、dialog 这些“进阶选手”值得用吗前面聊的基础标签是每个项目里最常出场的。HTML5 其实还有一些进阶语义标签用得好能提升结构化程度用不好就徒增复杂度。hgroup用于组合标题和副标题比如主标题“产品新版发布”副标题“v2.0 重点变化一览”。但它的浏览器支持和文档大纲算法在历史上有些波折现行标准里它被重新定义为“一组标题的组合”实践中如果有“主标题副标题”的场景可以用它包起来。不过说实话如果副标题本质是对主标题的说明用普通p再加适当的样式语义上也没有大问题。details配合summary可以实现“手风琴/折叠面板”而且不需要自己写 JS 状态管理。它的语义优势很明显用户代理可以原生管理展开/收起状态移动端体验更一致。但是要注意details 的默认样式在各浏览器间略有差异通常需要自己覆盖 reset。dialog是另一个被低估的标签原生支持模态框语义配合.showModal()可以在不使用复杂 ARIA 的情况下建立焦点陷阱和背景遮罩。兼容性在现代浏览器里已经可以接受如果你的项目不需要兼容特别老的浏览器可以考虑用它替代自造的 div 弹窗。我的建议是分两层看基础语义标签header、nav、main、article、section、aside、footer属于“必会技能”每个前端开发者都该熟练掌握进阶标签hgroup、details、dialog属于“按需使用”遇到匹配场景时用不要为了秀技术硬套。9. 一次真实改造某内容站语义化重构复盘前阵子帮某内容站一个技术博客类项目做结构重构那个项目的首页大概有几百个 div 嵌套页面权重集中在正文和列表上但爬虫抓取出来的内容摘要经常跑偏老是抓到侧栏的推荐阅读。我们做的第一步是盘点页面区块把所有可视区块按语义归类哪些是页眉、哪些是主导航、哪些是主内容、哪些是辅助内容、哪些是页脚。这一步不需要写代码纯靠“理解业务”来定边界。第二步是逐区块替换标签同时把原本依赖 class 的样式选择器跟着调整。这里有个实操建议语义化改造尽量跟样式重构解耦。先把标签换对、样式名沿用等结构稳定后再把 class 名规范一遍。否则一边改结构一边改样式出现问题很难定位而且改动范围不可控。第三步是在结构稳定后跑一轮大纲检查确认每个页面只有一个 main、h1 层级没有跳变、辅助内容都进了 aside。整个改造完成之后线上跑了一段时间最直观的变化是搜索引擎展示的页面摘要开始更精准地抓取正文首段读屏体验测试也顺畅了不少。这个项目的复盘给我最大的感受是语义化改造并不难难的是“判断每个区块该归到哪个语义层级”这件事而这件事恰恰是最需要跟产品经理、业务方沟通的部分。技术标签是死的业务理解是活的。10. 收尾语义化是一种“写得少、想得多”的工程习惯说句实在话掌握语义化标签的拼写和嵌套规则半天时间就够。真正拉开差距的是你面对任何一个页面模块时能不能迅速判断出它的内容性质和结构层级。这种判断力只能靠一次次实际项目里“多想一步”来积累。我现在写页面默认的思维路径是这样的先想清楚这个区块在文档大纲里的位置再写标签而不是先随手写个 div等代码成型了再琢磨“这里要不要换语义化标签”。顺序反了语义化就成了事后补救效率低且容易遗漏。如果你正在重构一个老项目我建议不要试图一次把所有页面全部改造完。先挑一个典型页面比如首页或详情页做全部改造同时把自己的选型判断沉淀成一份团队可用的“标签使用规范”文档后续改造照着执行就行。按我的经验页面之间的区块结构大同小异跑通三五个典型页面之后剩下都是复制判断逻辑而已。最后补一个我踩过坑后总结的实操小技巧在写完语义化结构后关掉 CSS 看一遍纯 HTML 的可读性。如果这时你还能清晰说出“这个页面的标题是什么、主体分区有哪些、侧栏在哪”语义化就做到位了。关掉 CSS 这个动作就是检验语义化的照妖镜。
阅读完成 · 觉得有帮助？
