浏览器解析html只认标签名和嵌套关系，不判断语义；语义影响在dom构建后的渲染、无障碍树及seo阶段：main映射role="main"且必须唯一，section需配标题才被识别为逻辑区块，article自动带role="article"并隔离大纲层级。
浏览器解析HTML时根本不管“语义”，只认标签名和嵌套关系
这是最容易被误解的一点：浏览器的HTML解析器（比如WebKit的HTMLTokenizer、Blink的HTMLParser）在构建DOM树阶段，不会判断你用DOCTYPE切换解析模式（quirks vs standards）。所谓“语义化影响解析”，其实是后续阶段的事——DOM树建好后，渲染引擎（Layout、Accessibility Tree）才开始读取标签名来推断意图。
main、section、article这些标签如何影响Accessibility Tree
屏幕阅读器不直接读DOM，而是依赖浏览器生成的Accessibility Tree（可访问性树）。这个树会把main映射为role="main"，nav映射为role="navigation"，但div默认是role="generic"。关键差异在于：
-
main元素只能出现一次，若页面中写了两个main，部分辅助技术会忽略第二个 -
section本身不带隐式role，必须配合h2–h6才能被识别为逻辑区块；光写<section><p>内容</p></section>在VoiceOver里可能就当普通容器读 -
article会自动带上role="article"，且其内部h1会被视为该文章的标题，不影响外层文档大纲层级
搜索引擎爬虫怎么利用语义标签做内容抽取
主流爬虫（如Googlebot）在首遍抓取时，优先解析静态HTML结构而非执行JS。它们用规则匹配+启发式权重给DOM节点打分，其中语义标签是强信号：
-
main内文本权重显著高于aside或footer中的相同文字 -
article会被单独切片索引，适合RSS订阅或聚合场景；如果把整站首页塞进一个article，反而会让爬虫误判为“单篇内容” -
header里的h1比section > h1更可能被当作页面主标题，但前提是它没被CSS设为display:none或visibility:hidden
注意：section不是SEO银弹——爬虫不会因为它存在就提升排名，但滥用（比如每个段落都包一层section）会导致内容碎片化，削弱主题聚焦度。
为什么嵌套过深会拖慢布局树构建
DOM树本身构建很快，真正卡顿常发生在后续的Layout Tree（布局树）生成阶段。浏览器要为每个节点计算样式、确定是否参与渲染流、判断是否需要创建图层。而div没有语义约束，编译器无法跳过无效分支；相比之下，main或article这类标签自带隐式呈现规则（例如main默认display:block且不继承overflow），V8或SpiderMonkey能做更多静态优化。
实测案例：某活动页将5层div替换成header+main+section+article+footer后，低端安卓机首次绘制时间（FP）下降210ms——不是因为标签“更快”，而是因为语义明确后，浏览器省去了大量无谓的样式继承推导和回流重排预判。
真正容易被忽略的是：语义标签的性能收益，从来不在解析那一刻显现，而在整个渲染管线的协同判断中悄然生效。
DOM树本身构建很快，真正卡顿常发生在后续的Layout Tree（布局树）生成阶段。浏览器要为每个节点计算样式、确定是否参与渲染流、判断是否需要创建图层。而div没有语义约束，编译器无法跳过无效分支；相比之下，main或article这类标签自带隐式呈现规则（例如main默认display:block且不继承overflow），V8或SpiderMonkey能做更多静态优化。
实测案例：某活动页将5层div替换成header+main+section+article+footer后，低端安卓机首次绘制时间（FP）下降210ms——不是因为标签“更快”，而是因为语义明确后，浏览器省去了大量无谓的样式继承推导和回流重排预判。
真正容易被忽略的是：语义标签的性能收益，从来不在解析那一刻显现，而在整个渲染管线的协同判断中悄然生效。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
