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