HTML语义化标签本身不改变视觉渲染，但影响读屏器、SSR、搜索引擎等对DOM的解析；nav需为body直接子元素且自带navigation landmark，div即使class="nav"也无语义；main必须是body直系子元素且唯一；form和button不可替代，否则丢失移动端原生能力；语义化须从首行HTML开始，非事后补救。
HTML语义化标签本身不改变视觉渲染结果，但在非标准阅读器、SSR 工具链、移动端 WebView 和搜索引擎中，会触发确定性行为——这种“优势”只在标签用对的前提下成立，错用反而导致内容不可见或结构崩塌。
为什么 nav 在 VoiceOver 里能一键跳入，而 div 类名完全静默
屏幕阅读器（如 VoiceOver、NVDA）不解析 CSS 类名，也不猜测开发者意图。它们依赖 DOM 中的原生语义和 ARIA role 绑定来构建可访问性树。nav 自带 role="navigation"，被固化为 landmark（地标），支持 N 键跳转；div class="nav" 的 computed role 是 generic，读屏器只当它是普通容器，连“导航”两个字都不会提。
- 多个
nav没加aria-label，全部朗读为“导航”，用户无法区分主导航、页脚导航或面包屑 - 用
div role="navigation"替代nav，但漏掉tabindex="0"，键盘用户根本无法聚焦 -
nav必须是body的直接子元素，否则某些 Android WebView 会忽略其 landmark 属性
main 被忽略的常见原因：DOM 位置和嵌套层级
main 不是“写上就生效”的标签。它必须是 body 的直接子元素，一旦被 div class="wrapper" 或 section 套住，辅助技术就无法识别为主内容锚点。用户按 M 键跳转时会失败，只能手动逐项下移——实测平均需按 14 次“下一项”才能抵达第一段正文。
- 检查方法：DevTools 控制台执行
document.querySelector('main').parentElement === document.body，返回true才算合格 -
main不能嵌套在header、footer、nav或section内部，否则部分 iOS Safari 会将其误判为新章节起点，甚至跳过 - 页面中只能出现一个
main，多写会导致语义冲突，SSR 工具（如 Next.js）可能丢弃后续的main
移动端 WebView 对 form 和 button 的硬性依赖
不用 form 包裹输入控件，等于放弃移动端原生能力：form 触发回车提交、autofill 关联、键盘「完成」按钮的 submit 行为；不用 button 而用 div onclick，iOS Safari 会强加 300ms 点击延迟，且不支持 type="submit" 或 type="reset" 语义。
立即学习“前端免费学习笔记（深入）”；
-
form的autocomplete属性（如autocomplete="email"）直接影响 Android 键盘弹出类型 -
button元素天然获得role="button"和焦点管理，无需额外tabindex或 JS 模拟 - 微信内置浏览器对
nav和form的 focus 管理更稳定，但对嵌套在div里的同功能结构无响应
SSR 和爬虫只读 DOM + ARIA，不执行 JS
Next.js 的 next/image 在 SSR 阶段识别到 figure + img + figcaption 结构，自动注入 loading="lazy" 和宽高属性；搜索引擎爬虫看到 time datetime="2024-12-01" 才能正确索引日期，缺 datetime 属性时，iOS Safari 不触发「添加到日历」快捷操作。
- 旧版 IE（≤IE9）不识别语义标签，必须通过
html5shiv或document.createElement预声明，否则 DOM 结构被破坏 - 语义缺失不是“不好看”，而是“不可见”——爬虫和读屏器根本不执行 CSS/JS，只靠 DOM 标签 + ARIA 组合判断内容权重与结构
- 用
section替代三层div嵌套，直接减少 2–3 个 DOM 节点，移动端首屏渲染快约 6ms，布局重排开销降 40%
最容易被忽略的是：语义化不是“补救措施”，而是从第一行 HTML 就决定结构。比如一个卡片组件，开头就该是 article 而不是 div class="card"；footer 必须关联最近的节段祖先（body 或 section），单独丢在 DOM 底部却不包裹任何内容，部分安卓 WebView 会忽略其语义。
