语义化标签虽不直接适配多终端，却是响应式与无障碍生效的前提；它确立dom逻辑层级、提升可访问性、增强seo、稳定渲染，并为媒体查询提供可靠选择器。
HTML语义化标签本身不直接参与多终端适配，它只负责结构表达；真正起适配作用的是 CSS 媒体查询、视口设置和响应式单位（如 rem），但语义化结构是这些适配手段能稳定生效的前提。
为什么 <header></header> <nav></nav> <main></main> 这些标签不影响屏幕尺寸，却必须先写对
因为语义化标签决定了 DOM 的逻辑层级和可访问性上下文。比如移动端屏幕阅读器会按 <nav></nav> → <main></main> → <footer></footer> 的顺序朗读，若你用 <div class="nav"> 替代 <code><nav></nav>，辅助技术就无法识别这是导航区，用户可能跳过关键入口。更实际的影响是：JavaScript 脚本或 CSS 选择器（如 nav a）在响应式切换时依赖这个结构，一旦结构错乱，@media 规则里写的 nav { display: flex; } 就可能失效或匹配到错误节点。
- 浏览器对
<nav></nav>等标签有默认的 ARIA role 映射（如role="navigation"），无需额外加aria-label - SEO 爬虫会把
<main></main>当作页面核心内容区，忽略<aside></aside>里的广告或推荐，这对移动搜索结果排序很关键 - 在微信内置浏览器或某些低端 Android WebView 中，非语义化结构更容易触发渲染 bug（比如
position: sticky在<div> 上失效，但在 <code><header></header>上正常）@media查询中怎么配合语义化结构做差异化布局语义化标签不是摆设，它们是你写媒体查询时最可靠的钩子。比起靠一堆
class名去猜结构，直接用原生标签名更稳定、更少歧义。- 移动端折叠
<nav></nav>：用@media (max-width: 768px) { nav { height: 0; overflow: hidden; } }，再配合 JS 切换aria-expanded属性 - 平板横屏显示
<aside></aside>：用@media (min-width: 769px) and (orientation: landscape) { aside { display: block; } }，<aside></aside>的语义天然表明它是“附属内容”，适合在宽屏时侧边展示 - 避免在
<main></main>里塞display: grid后又用grid-column: span 2打乱流式阅读顺序——屏幕阅读器仍按 DOM 顺序读，视觉顺序和语义顺序不一致会导致移动端用户困惑
移动端
<viewport></viewport>和语义化标签的隐性配合点<meta name="viewport" content="width=device-width, initial-scale=1">是响应式的起点，但它只有在语义结构清晰的前提下才能发挥最大价值。比如：- 没有
<header></header>，你很难用 CSS 安全地固定顶部栏（position: sticky在无语义容器里容易被父级transform或overflow截断） - 如果用
<div id="footer"> 替代 <code><footer></footer>，iOS Safari 在键盘弹出时可能错误计算页面高度，导致<footer></footer>被顶出可视区——而原生<footer></footer>有更稳定的滚动锚点行为 -
<section></section>和<article></article>天然支持scroll-margin-top，你在@media里给它们设scroll-margin-top: 60px，就能让锚点链接跳转后避开固定<header></header>，这个能力在纯<div> 结构中需要额外 hack <p>真正容易被忽略的是：语义化不是“写完再补”的装饰项，而是在第一行 HTML 就要决定的事。一旦用 <code><div class="card"> 开始搭建，后面所有媒体查询、JS 交互、无障碍测试都会被迫绕着这个“假结构”打补丁。多终端适配的稳定性，是从 <code>标签开始的语义连贯性决定的，不是靠最后加几个@media勉强撑起来的。
- 移动端折叠
