div不是语义缺陷而是设计选择，适用于无内容语义的交互组件、纯布局容器及动态/封闭环境场景，硬套语义标签反而失真且有害。

div 不是语义缺陷，而是设计选择。该用就用，硬套语义标签反而让结构失真。

软件界面和交互组件不适用语义化标签

按钮、表单控件、图表容器、弹窗、标签页、轮播图这些模块，核心是行为而非内容。它们没有独立发布价值，也不构成文档大纲节点。

• article 要求可脱离页面独立存在（如 RSS 抓取），而一个“设置面板”显然不能
• section 必须有标题且表达逻辑主题，但“开关组”或“进度条”只是状态呈现，无章节语义
• 用 <div role="tablist"> 比硬套 <code><section></section> 更准确——ARIA 属性直接声明交互意图

  纯布局容器不该塞语义标签

  CSS Grid / Flex 的 wrapper、响应式断点分组、间距控制层，只服务样式与对齐，不承载任何内容含义。

  

  html-ppt-to-pdf

  将使用 `

  ` 约定的 HTML 幻灯片转换为高保真、矢量文本 PDF（使用 Playwright + Chromium 原生 PDF 功能）。

  下载
  • 写 <section class="grid-wrapper"></section> 却没配 <h2></h2>，等于在无障碍树里塞了个空节点
  • Grid 子项若只是图标+文字卡片，且无独立语义（比如不是新闻条目），用 <div class="card"> 比 <code><article></article> 干净
  • 构建工具生成的骨架屏（skeleton）、加载占位符，外层必须用 div，否则会误导爬虫认为“这是真实内容”

  动态渲染或 SSR 不确定的场景要谨慎

  React/Vue 组件返回值、CMS 动态拼装的区块、条件渲染分支，语义层级可能运行时才确定。

  • 服务端模板里漏判 if 分支，导致多个 <main></main> 同时输出，Lighthouse 直接报 “Multiple main landmarks”
  • 从 Markdown 渲染出的 <h3></h3> 插入已有 <h1></h1> 页面，跳级破坏大纲，但你无法提前约束 CMS 输出
  • 此时优先用 <div role="region" aria-labelledby="xxx">，比强行匹配 <code><section></section> 更可控

    无 SEO 和无障碍需求的封闭环境

    微信小程序、Electron 内嵌页、政企内网旧终端、IoT 设备 Webview，语义标签既不被解析，也不被消费。

    • 小程序用 <view></view> 就够了，<header></header> 在 WebView 里不会触发任何辅助功能
    • 某些定制内核浏览器（如部分银行系统）仍跑在 IE9 兼容模式，<nav></nav> 被当普通行内元素，还得补 display: block
    • 若项目连 Lighthouse 都不跑、也不测 VoiceOver，那语义标签就是装饰性代码，徒增体积和维护负担

    最常被忽略的一点：语义标签一旦用错，比不用更糟——它会向机器发出错误信号，且难以被 CSS 或 JS 修正。判断依据永远是“这块内容对用户或机器意味着什么”，而不是“它看起来像不像页眉”。