语义化html标签在移动端是影响渲染、无障碍和seo的关键结构节点，而非可选装饰；必须正确使用（仅一次）、（仅主导航）、与（依内容独立性区分）、（补充信息非侧边栏）。
<header></header>、<nav></nav>、<main></main>、<section></section>、<aside></aside>、<footer></footer> 这些标签在移动端不是“可选装饰”，而是影响渲染逻辑、辅助技术识别和 SEO 抓取的关键结构节点。用错或滥用，轻则导致屏幕阅读器跳过关键内容，重则让搜索引擎降权页面主体。
移动端 <main></main> 必须且只能出现一次
很多开发者在单页应用（SPA）中嵌套多个 <main></main>，比如每个路由组件都包一层——这是错误的。<main></main> 表示整个文档的**唯一主要内容区域**，浏览器和读屏软件依赖它快速定位核心信息。
- 错误写法：
<main><h2>首页</h2></main><main><h2>详情页</h2></main> - 正确做法：只在最外层
下保留一个<main></main>，内部用<section></section>或<article></article>划分子模块 - 注意：iOS Safari 16.4+ 开始对重复
<main></main>发出控制台警告，部分无障碍工具直接忽略后续出现的<main></main>
<nav></nav> 不等于所有链接容器，只用于主导航
把面包屑、分页、相关文章链接、底部友情链接全塞进 <nav></nav>，会稀释语义权重。移动端屏幕小，辅助技术更依赖精准导航定位。
- 应该用
<nav></nav>的场景：顶部固定菜单、底部 Tab 栏（如<nav aria-label="底部导航"></nav>） - 不该用的场景：文章末尾的“上一篇/下一篇”、侧边栏推荐链接（改用
<aside></aside>）、页脚的备案链接（保持<footer></footer>内原生结构） - 补充技巧：给
<nav></nav>加aria-label（如aria-label="主导航"），避免多组<nav></nav>时读屏器无法区分
<section></section> 和 <article></article> 的边界容易混淆
两者都表示“独立内容块”，但判断依据不是视觉样式，而是内容是否具备**可独立分发性**。
-
<article></article>：适合单独被 RSS 抓取、转发或存档的内容，比如博客正文、新闻稿、用户评论 -
<section></section>：只是逻辑分组，比如“产品特性列表”、“客户评价轮播区”，不能脱离当前页面存在 - 常见坑：把轮播图容器写成
<article></article>—— 轮播项本身不是独立内容单元；把整篇图文报道拆成多个<section></section>而不用<article></article>—— 错失语义强化机会 - 移动端特别注意：某些安卓 WebView 对
<article></article>的默认 margin 处理不一致，建议显式重置margin: 0
<aside></aside> 在移动设备上不是“隐藏侧边栏”的替代方案
很多人以为 <aside></aside> 就是 PC 端侧边栏的响应式版本，其实它的语义是“与主内容相关但可分离的补充信息”。在移动端，它常出现在主内容流内部，而非物理侧边。
- 适用内容：文章中的术语解释框、作者简介卡、广告位（需加
role="complementary"明确意图）、引用来源说明 - 不适用内容：折叠菜单弹层、底部操作浮层（这些属于交互控件，应使用
<dialog></dialog>或带role="menu"的<div>） <li>关键细节：如果 <code><aside></aside>位于<article></article>内部，它代表该文章的附属信息；若在级别，则代表整页的补充内容（如全站公告）
语义化标签在移动端真正起作用的地方，往往不在视觉呈现，而在 DOM 解析顺序、焦点管理路径和辅助技术遍历逻辑里。写完结构后，用 iOS 的 VoiceOver 或 Android TalkBack 实际走一遍，比任何 validator 都更能暴露问题。
