header、nav、main、footer不可替换为div，因为前者自带隐式aria role，能被浏览器和读屏软件识别为语义结构，而div无语义，会导致可访问性失效和seo主次判断缺失；main必须唯一，section须配h2+标题才生效，article需可独立分发。
为什么和不能换成
因为浏览器和读屏软件会直接识别 header、nav、main、footer 的隐式 ARIA role，而 div 没有语义含义。用 div 替代这些标签，等于主动放弃可访问性支持和搜索引擎对内容主次的判断依据。
常见错误现象：页面在 VoiceOver 或 NVDA 下导航混乱，SEO 工具提示“缺少主内容区域标记”。
-
main 必须且只能出现一次，代表页面核心内容；多个 main 会被部分读屏器忽略
-
header 和 footer 可以嵌套使用（如文章内也有 header），但父级 header 应位于 body 直接子节点层级附近
- 不要给
main 加 role="main"——它本身已有该 role，重复声明反而可能干扰旧版辅助技术
section 和 article 到底该不该加？
section 和 article 不是“多写点语义就更好”的装饰品，它们只有在满足结构前提时才真正生效。
典型误用场景：把侧边栏广告、分页导航、纯样式容器都包进 section；或把整页内容塞进一个没标题的 article。
-
section 必须配 h2 或更高级别标题才有语义价值；单独一个无标题的 section 和 div 在可访问性上完全等价
-
article 表示可独立分发/复用的内容单元（如博客正文、新闻条目），不是所有带标题的区块都是 article
- 嵌套
section ≤ 3 层：超过三层后，读屏器会开始混淆逻辑层级，Chrome DevTools 的 Accessibility 面板也会标出“结构过深”警告
DOM 节点数卡在多少才算安全？
不是“越少越好”，而是单个父容器下子元素建议 ≤ 50 个——这是 Chrome 样式计算时间开始非线性增长的实测拐点。
容易被忽略的影响：一个含 200 项的菜单列表，比 20 个结构清晰的 section 更拖慢首屏渲染，尤其当这些子项还绑了事件或带 style 属性时。
- 表格类数据慎用
table 渲染万级行：其 layout 算法是 O(n²)，哪怕设了 table-layout: fixed，首行解析仍会卡顿
- 动态插入大量内容时，必须用
DocumentFragment 批量挂载；逐个 appendChild 100 次 = 触发 100 次重排
- iOS Safari 对 flex 容器嵌套 > 5 层时帧率明显下跌，这不是理论值，是真机实测结果
语义标签和性能到底怎么平衡？
语义化不是性能的对立面，但滥用语义标签会制造新问题：比如为每段文字加 section 导致 DOM 膨胀，或用 nav 包裹非导航链接造成逻辑污染。
真正卡准临界点的做法，是让每个语义标签都带来可验证收益——要么提升可访问性，要么简化 JS 查询，要么帮助搜索引擎理解权重分布。
- 检查是否高频使用
document.querySelectorAll('div div div div') 类选择器；如果存在，说明结构本身就在增加维护成本，而非语义缺失
- 用 Layers 面板看是否有“合成层爆炸”：某些看似扁平的结构，因
transform 或 will-change 被强制分层，反而更耗 GPU 资源
- 移动端尤其注意：语义标签本身不耗性能，但深层嵌套 + flex 布局 + 动态 class 切换，三者叠加容易触发 iOS WebKit 的渲染 bug
因为浏览器和读屏软件会直接识别 header、nav、main、footer 的隐式 ARIA role，而 div 没有语义含义。用 div 替代这些标签，等于主动放弃可访问性支持和搜索引擎对内容主次的判断依据。
常见错误现象：页面在 VoiceOver 或 NVDA 下导航混乱，SEO 工具提示“缺少主内容区域标记”。
-
main必须且只能出现一次，代表页面核心内容；多个main会被部分读屏器忽略 -
header和footer可以嵌套使用（如文章内也有header），但父级header应位于body直接子节点层级附近 - 不要给
main加role="main"——它本身已有该 role，重复声明反而可能干扰旧版辅助技术
section 和 article 到底该不该加？
section 和 article 不是“多写点语义就更好”的装饰品，它们只有在满足结构前提时才真正生效。
典型误用场景：把侧边栏广告、分页导航、纯样式容器都包进 section；或把整页内容塞进一个没标题的 article。
-
section必须配h2或更高级别标题才有语义价值；单独一个无标题的section和div在可访问性上完全等价 -
article表示可独立分发/复用的内容单元（如博客正文、新闻条目），不是所有带标题的区块都是article - 嵌套
section≤ 3 层：超过三层后，读屏器会开始混淆逻辑层级，Chrome DevTools 的 Accessibility 面板也会标出“结构过深”警告
DOM 节点数卡在多少才算安全？
不是“越少越好”，而是单个父容器下子元素建议 ≤ 50 个——这是 Chrome 样式计算时间开始非线性增长的实测拐点。
容易被忽略的影响：一个含 200 项的菜单列表，比 20 个结构清晰的 section 更拖慢首屏渲染，尤其当这些子项还绑了事件或带 style 属性时。
- 表格类数据慎用
table渲染万级行：其 layout 算法是 O(n²)，哪怕设了table-layout: fixed，首行解析仍会卡顿 - 动态插入大量内容时，必须用
DocumentFragment批量挂载；逐个appendChild100 次 = 触发 100 次重排 - iOS Safari 对 flex 容器嵌套 > 5 层时帧率明显下跌，这不是理论值，是真机实测结果
语义标签和性能到底怎么平衡？
语义化不是性能的对立面，但滥用语义标签会制造新问题：比如为每段文字加 section 导致 DOM 膨胀，或用 nav 包裹非导航链接造成逻辑污染。
真正卡准临界点的做法，是让每个语义标签都带来可验证收益——要么提升可访问性，要么简化 JS 查询，要么帮助搜索引擎理解权重分布。
- 检查是否高频使用
document.querySelectorAll('div div div div')类选择器；如果存在，说明结构本身就在增加维护成本，而非语义缺失 - 用 Layers 面板看是否有“合成层爆炸”：某些看似扁平的结构，因
transform或will-change被强制分层，反而更耗 GPU 资源 - 移动端尤其注意：语义标签本身不耗性能，但深层嵌套 + flex 布局 + 动态 class 切换，三者叠加容易触发 iOS WebKit 的渲染 bug
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
