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。

立即学习“前端免费学习笔记（深入）”；

html-to-pptx-converter

使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。

下载

• 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