1. 满屏 div 的真实代价——先聊聊我为什么劝你别再万能容器了先说个我自己的真实经历。前几年接手过一个后台管理系统打开页面源码的一瞬间我人麻了整个页面的主体结构是div套div套div最深的层级到了十几层每个 div 还带着classNamebox1 box2 box3这种毫无信息量的命名。当时排查一个样式错位问题光定位这个 div 是哪一个就花了大半天最后发现是某个组件内部多包了一层没有实际作用的容器。那个瞬间我就下了一个决心能用语义化标签写清楚的绝不用 div 凑合。很多同学觉得div 加 class 不也能用吗这话没错div 确实能完成所有布局需求但它有一个致命的问题——它本身不携带任何含义。浏览器不知道它是导航还是页脚屏幕阅读器不知道它是不是主要内容SEO 爬虫分不清哪个区块才是正文你的同事更看不懂这一层一层嵌套到底谁是谁。你写的代码最终是给人看的。人看代码最快的方式是扫结构而结构是否清晰很大程度取决于标签本身讲不讲话。nav一摆出来谁都知道这里是导航footer一出现自然知道这里是页脚。而 div 呢它只会沉默地站在那里等你用 class 去给它贴标签——问题是 class 是你们团队的私有约定换个人来看等于没有。再有HTML5 语义化标签这事从来不是理论正确但没用的花架子。它直接影响三件实事无障碍访问屏幕阅读器依赖语义标签来朗读页面结构、SEO 收录搜索引擎给语义清晰的内容更高权重、开发协作效率结构即文档省去大量沟通成本。这三条随便哪一条落到实处都是实打实的收益。所以这篇我把自己在实际项目中总结的语义化标签使用经验完整盘一遍包括每个标签的适用场景、边界判断、常见误用以及怎么从一团乱麻的 div 堆里做渐进式重构。适合刚接触 HTML5 不久的同学当入门图谱也适合写了一阵子业务代码但没认真梳理过语义化逻辑的同行查漏补缺。2. 核心标签逐个拆解——每个标签都该用在哪里、不该用在哪里HTML5 新增的语义化标签一共就那么几个header、nav、main、article、section、aside、footer外加一个没怎么被讨论但很重要的figure和figcaption。逐个盘点一下顺便把最常见的使用误区标出来。2.1 header不只是顶部那一条header在很多人脑子里约等于页面的顶部区域其实它的定义比这宽——它代表的是一个区块的引导区域。也就是说它既可以放在页面顶部也可以放在article里、section里甚至放在一个商品卡片里。article header h2产品功能更新日志/h2 p发布时间2024年6月18日 · 阅读约 3 分钟/p /header p正文内容……/p /article注意header并不一定出现在页面最顶端它只要求在它所处的那个区块内承担引导职责。有些页面顶部是纯广告横幅或通知条这种情况没有必要硬套header把真正的站点头部区留给header更准确。另一个容易犯的错是在header里堆太多东西。logo、搜索框、登录按钮、导航、副标题全部塞进去标签本身失去引导的语义纯度。它跟nav是两回事header负责呈现“这个区块的前言、标题、简介”nav才负责“链接跳转的导航集合”二者职责分开写更健康。2.2 nav不是所有链接列表都是导航很多人看到页面上有一组链接就随手套nav其实nav只服务于“主要导航区块”——比如站点主菜单、侧边栏的章节目录、分页器pagination。而像友情链接、文章底部的相关阅读这类次要链接集合没有用nav的必要ul li就足够。判断标准很直接删掉它用户找关键路径是否受影响如果是那它是导航如果只是内容性的链接罗列别用nav抢戏。导航里我特别推荐配合ul构建而不是裸写一堆a。这个习惯对无障碍支持很关键读屏工具会把ul内的项目自动作为列表朗读用户能明确感知这里有 5 个导航项。nav aria-label主导航 ul lia href/首页/a/li lia href/posts文章/a/li lia href/tools工具箱/a/li /ul /nav有个细节一个页面允许有多个nav但每个nav都应该配上aria-label区分用途比如主导航、页脚导航、文档目录这样依赖辅助技术的用户不会被两个相同的导航搞晕。这个细节我在实际无障碍测试里实测过不标注的话读屏软件会念出两个一模一样的导航 导航体验很差。2.3 main一页只有一个别客气main的语义非常明确代表页面独一无二的主体内容。它和article的区别在于article 可复用一个页面可以有多个而 main 在一个页面里只能出现一次而且不应该被包在其它语义区块里面。实际项目里我会把 main 当作整个内容区域的锚点body header站点头部/header div classlayout nav目录导航/nav main article正文/article /main aside侧边栏/aside /div footer页脚/footer /body有同学会问main 里面不能有自己的 header 和 footer 吗可以这种结构完全合法这也呼应了前面说的header、footer 是局部的这层意思。一个要注意的操作点单页应用里如果内容切换是动态渲染的给main挂一个可见但可跳过的a href#main-content跳至正文/a链接是极好的无障碍实践同时记得在main上加tabindex-1才能让焦点正确移动。这个小组合很多团队不做但你做了用户体感差别很明显。2.4 section 和 article一对最容易被搞混的兄弟这俩是最多人用错的一组核心区别一句话能说清article 是完整的、可独立成篇的内容单元section 是内容内部的专题分区。举个例子一篇长文里有三个观点板块那这篇文章是article每个观点板块是section。如果一个页面上展示的是用户发布的多个帖子那每个帖子都可以是一个article它们之间互不依赖。但只有这个判断还不够我常用的实操标准有两板斧如果这段内容摘出来放进一个独立的网页里依然成立、完整、有意义——是 article如果它是某个更大内容主题的一个子主题区块单独拿出来略显单薄——是 section。另外section一般建议配一个标题标签h1-h6因为它暗示着一个独立主题的开始。没有标题却又要用 section多半说明应该换成 div。2.5 aside别只当侧边栏使用aside的官方语义是和周边内容只有间接关系的部分最常见的形态确实是侧边栏但它也能用在正文中间——比如文章里的名词解释、引用说明、相关材料补充。我比较常见的一个场景是产品详情页商品参数表格用aside放在正文侧边这样读屏用户能在正文阅读和参数查看之间明确切换。如果用 div读屏会把它当作正文的一部分连续朗读内容跳来跳去非常难受。2.6 footer页脚的微小信息也别闲置它和header一样footer出现在一个区块的结尾处即可不一定非要页面底部。文章底部放 作者信息、版权声明、标签集合 是很合适的footer场景article h1深入理解 CSS 容器查询/h1 p正文内容……/p footer p作者某某 · 标签#CSS #响应式/p /footer /article版权信息、联系方式、站点地图链接放页面级 footer 没毛病但是别学一些反模式把 footer 当悬浮条、把整个页面的所有版权声明都堆进每个区块的 footer 里那样反而让语义错乱。2.7 figure 与 figcaption图片专属的语义补位figure这个标签被索引的概率远低于它应有的地位。它承载的是插图、图表、代码片段等自带独立说明的内容配合figcaption可以形成语义完整的图片单元。figure img srcarchitecture.png alt系统架构图 figcaption图 1订单模块整体架构/figcaption /figure如果你还在用p包img再在下面写一行灰色小字当图片说明试试换成figure figcaption至少在语义上这个小单元变成了一块完整的内容而且默认样式也省得你手调不少。3. 最容易翻车的选择困难症——div、section、article 到底怎么快速拍板写语义化标签最耗神的就是面对一块内容犹豫半天这是 section 还是 article还是干脆用 div 我的建议是把判断变成条件分支几步走完不要靠感觉。实际写码时我内心跑的是下面这套流程。3.1 第一步先看内容能否独立存在问自己一个问题如果把这段内容单独放到一个页面读者会觉得突兀吗不突兀说明它有完整的独立性直接选article。举两个对比首页上展示的最新 3 条公告每条公告有自己的标题、摘要、时间——每条都可以单独抽出来看所以每条公告都是一个article公告下面热门标签区域里面的标签云只是容器内的聚合信息哪来的独立性它不是 article也不是 section用ul或者干脆div最合适。3.2 第二步判断是否属于主题下的子分区内容独立不了但有明确的小主题比如第一章核心优势操作步骤并且这个小主题应该作为整个页面大纲的一部分出现那用section。关键点是 section 通常会让文档大纲多一层子标题。如果这个主题标题不进大纲也不影响理解说明它只是视觉拆分的产物div 更诚实。3.3 第三步两者都不是——恭喜你可以安心用 divdiv 不是敌人无脑滥用 div 才是。真正该用 div 的场景特别朴素纯布局容器比如 flex 排布的外层包裹没有独立语义的装饰性分组JS 操作需要但不需要语义的钩子这类情况下硬套 section / article属于矫枉过正。语义化追求的是忠实表达内容结构不是给每个标签都贴金。能诚实用 div 的地方就大方用 div该语义化的地方也别偷懒。3.4 一个兜底的通用判断表我把这个判断逻辑整理成了速查表贴给我团队新人用的这里也直接分享出来场景特征推荐标签不推荐原因内容独立成篇、可单独传播articlesection 会让文章独立性变弱大主题下的子主题分区sectionarticle 语义过重主要链接集合菜单、目录navdivp 无法传达导航语义当前页面唯一主体区域main多个 main 违反 HTML 规范与主内容只是间接相关asidediv 无法体现间接性纯布局包裹、无语义需求divsection/article 会造成语义污染这个表我实际用下来准确率很高。先判断独立性再判断主题性两者皆否就放它去 div。4. 从 div 到语义化一次真实页面的渐进式重构全记录理论讲再多不如看一个真实重构过程。我拿之前给一个团队做的产品文档首页改造当案例拆解。原页面大概五六屏长全部由 div 搭建负责的同学说当时只求快点上线没想语义这回事。这种说法我不止一次听到但讲真重构并不需要推翻一切渐进式整改完全可行。4.1 重构前的代码状态原结构大致如下div classcontainer div classtop div classlogoLOGO/div div classnav a href#文档/a a href#API/a a href#社区/a /div /div div classcontent div classsidebar a href#快速开始/a a href#安装配置/a /div div classarticle h2快速开始/h2 p欢迎使用……/p /div /div div classfooter span© 2024/span /div /div单从视觉看没什么毛病但语义上几乎没给任何线索。盲人用户使用读屏工具时听到的是一串没有层级结构的 div根本无法跳过导航直接读正文。4.2 第一次重构标签替换class 保留第一次不用动太多先把外层标签换了class 可以留着当作样式挂载点body header classtop div classlogoLOGO/div nav classnav aria-label主导航 a href#文档/a a href#API/a a href#社区/a /nav /header div classcontent nav classsidebar aria-label文档目录 a href#快速开始/a a href#安装配置/a /nav main classarticle h1快速开始/h1 p欢迎使用……/p /main /div footer classfooter p© 2024/p /footer /body注意我做了两个额外动作一是给两个nav加了aria-label区分二是把原来的h2在 main 语义下提升成h1。后者是很多人忽略的页面主体标题应该是文档大纲的第一级从 h1 开始否则大纲树缺失根节点。4.3 第二次优化进一步细分区块边界第一次替换只解决了表面标签里面还有改进空间。产品文档首页有三个章节每个章节下又有若干小节这些内容应该是section加标题的组合main h1产品文档/h1 section aria-labelledbygetting-started h2 idgetting-started快速开始/h2 p……/p /section section aria-labelledbyinstallation h2 idinstallation安装配置/h2 p……/p /section /mainaria-labelledby和标题 id 关联之后每个 section 的名称会直接被读屏软件报出来用户进入区块前就知道接下来这个区域讲什么。这一步在原始 div 阶段是根本做不到的。4.4 重构后的实际效果重构完成以后我做了三次检查控制台检查无 HTML 嵌套错误main唯一、header/footer层级正确大纲检查用浏览器的 Reader View 和 W3C HTML Checker 过了一遍文档大纲结构清晰从 h1 到 h3 没有跳级读屏实测用 NVDA 从页面顶部开始听导航、正文、页脚都能被准确播报跳转快捷键按 H 跳标题、按 1 跳一级标题完全生效。重构前后视觉零变化但结构可感知度完全不在一个级别。这也是语义化的核心价值它不让你做得更多但让你的代码向所有消费方打开一个信息通道。5. 别栽在细节里标题层级、兼容性和 SEO 那些事标签选对了几个容易翻车的细节也要处理干净。5.1 标题层级h1 的分布规则比想象中严格HTML 规范不限制页面只能有唯一 h1很多站点也会在多个区块设置 h1。但从文档大纲的清晰度考虑一个页面的主导航入口最好只有一个 h1副标题、区块标题用 h2/h3 逐级展开。如果多个区块各自有 h1读屏用户快速浏览时听到的每一个一级标题都会被认为是一个新页面的开始误导性极强。实际开发里我给团队定的规矩是这样页面区域推荐的标题级别页面级主体标题h1页面内至多 1-2 个区块标题section/article 内h2 或 h3区块内的子标题按内容层级递进页脚、次要辅助区域不设置标题或 h3 以上尽量不要跳级不要从 h2 直接蹦到 h4这样既照顾了大纲结构也让阅读体验更顺畅。5.2 兼容性别被老浏览器不支持吓住HTML5 语义标签的兼容性放在今天根本不是问题所有现代浏览器原生支持。如果项目里确实存在必须兼容远古浏览器的场景比如某些政府系统内部浏览器还是 IE8 级别那就需要给这些标签补上默认样式和 HTML5 shiv 方案。老项目里我见过比较稳妥的做法是npm install html5shiv然后手动给语义元素添加display: block。但说实话这类存量项目的治理优先级极低新项目请直接用 HTML5 语义标签不要再搞降级方案因为你每个降级样板都在给未来的维护者埋雷。5.3 SEO 的真相语义标签的作用是更容易被理解关于 SEO需要泼一点冷水语义化标签不是排名开关不是说加了article关键词排名就能立刻冲第一。它对 SEO 的真实作用在于——搜索引擎的爬虫和结构化解析器能更准确地理解页面的主题分布、主次关系、链接权重分配。如果你的页面上有十个并列 div爬虫对哪些内容才是本页最重要的核心段判断难度很大但如果你用了main article section这种结构爬虫能轻松定位核心内容区块。所以语义化利于 SEO这个说法没错但它是间接收益别把它当魔法。5.4 aria 是语义化的延伸不是替代最后特别提醒一句ARIAAccessible Rich Internet Applications是语义化标签的补充不是备胎。有些同学一出手就喜欢给 div 挂一堆rolenavigation、rolemain等于把语义化标签应该做的事用 ARIA 硬拗回来。结果代码又长又难以维护。正确顺序是优先用原生语义化标签原生的做不到再用 ARIA 补位。比如div加roleheading这种事不如直接用h2div加rolenavigation不如直接用nav。原生标签不仅自带语义还自带键盘交互和默认样式ARIA 只负责雪中送炭不负责锦上添花。6. 一条务实路径新项目怎么定规矩老项目怎么逐步解套看完上面的内容如果你决定动手改造我给一条实际的落地路径按优先级排序。6.1 新项目用模板和 eslint 一起兜底新项目开局就定好规矩最省事。我给团队推荐的基线方案页面骨架固定用header / nav / main / footer四个标签搭底正文列表项用article包裹配合h2标题侧边辅助内容统一aside纯布局容器保留div但class命名禁止使用box1这种无意义名称代码规范层面可以装一个 eslint 插件做语义化标签检查提前拦截明显的错误用法。6.2 老项目按页面级 → 区块级 → 内联级三层递进老项目改造不建议一次性推翻出一个大 Diffcode review 量大不说还可能改出样式问题。我走的是三层递进路线页面级改造只把最外层骨架的 div 替换成 header/nav/main/footer视觉影响极小但结构和读屏收益立刻显现区块级改造逐步把列表页的卡片容器、详情页的正文容器换成 article/section模块内冲突只会影响局部内联级改造把图片、引用、说明语块换成 figure/figcaption/blockquote 等更细的语义标签这类改造不紧急随每次迭代顺手做就行。这种渐进式路线最大的好处是每一次改动都可测试、可回滚、可单独合并不会因为语义化重构而阻塞正常业务迭代。6.3 保持语义纯度的日常小习惯养成三个小习惯语义化的意识自然就有了写完每一块 DOM先回头看一眼标签是否说了人话——如果标签换成 class 才能懂那这标签大概率选错了所有交互入口优先保证是a或button不要只依赖 div 加onclick不只语义好键盘操作也天然可用每次 commit 里如果出现大段 div发 PR 时先默问一句——这里真的不需要语义吗我个人在实际项目中的体会是语义化标签上手门槛极低难的是克制和判断选标签不是越语义越好而是越准确越好。div 依旧是万能容器里最诚实的选择但当你发现某个容器实际上承载着导航正文独立内容这些含义时换掉它就不只是代码洁癖而是对代码消费方最基本的尊重。下次再有人跟你抬杠反正 div 也能实现你可以温柔地回一句能实现和表达清楚是两码事。