是。div与语义标签混用会破坏HTML语义，导致辅助技术无法正确解析结构；关键判断标准是去除CSS后结构是否仍可读、可导航、可索引。
结构标签和 div 混用时，语义是否被悄悄破坏？
会。只要在不该用 div 的地方用了，HTML 就开始“失语”——浏览器、屏幕阅读器、搜索引擎都收不到你想表达的结构意图。比如把 nav 里套一层无意义的 div，再加 class="nav-wrapper"，那 nav 的导航语义就卡在第一层，后面所有嵌套都变成“视觉容器”，而非“功能区域”。
关键判断标准不是“能不能渲染出来”，而是“去掉 CSS 后，结构是否仍可读、可导航、可索引”。
-
header/
footermain等全局结构标签，每个页面最多出现一次（article内部可嵌套自己的header，但那是局部语义） - 不要用
div替代有明确语义的标签：比如button按钮写成，不如直接用button；同理，列表必须用ul/ol，不用div+class="list-item"- 当需要额外容器做样式隔离（如 flex 包裹、margin 控制），优先用语义中性但合法的
section或article，其次才是div—— 前提是它不承担内容角色div在语义化布局中还能不能用？怎么用才安全？能用，但只用于“纯样式分组”或“临时逻辑包裹”，且必须满足两个条件：不改变内容层级、不干扰 ARIA 解析路径。
常见安全用法：
- 作为 CSS Grid / Flex 容器的直系子元素，仅用于对齐控制：
- 在已有语义标签内部做样式分层，比如
article里用div class="article-content"包住段落，只要不把h1、p等内容标签包错层 - 动态插入内容时的占位容器（如 React 中的
），这类div不参与语义流，完全合理
危险信号：
div里包含多个h2却没有section包裹；div class="card"实际承载独立新闻条目却没升级为article。遇到 CMS 输出一堆
div怎么补救？不能靠 JS 注入语义标签来“修复”——那只是骗过了开发者，没骗过辅助技术。真实可行的补救只有两条路：
- 在模板层用
data-属性标注原始语义，再配合role和aria-*显式声明，例如：标题
正文
- 用服务器端或构建时工具（如 PostHTML 插件）自动将特定
class映射为语义标签，例如把转成，前提是 class 命名规范、无歧义- 如果 CMS 输出不可控且无法改造，至少确保每个
div都有role和必要aria-*属性，否则等于放弃语义化底线检查语义是否被混用破坏，最有效的手段是什么？
关掉 CSS，用键盘 Tab 导航，同时打开浏览器的「辅助功能树」面板（Chrome DevTools → Elements → 右键节点 →
Inspect Accessibility Properties）。这时候你会立刻看到：- 哪些
div被识别为generic（语义丢失） - 哪些本该是
navigation的区域被标记为complementary（因为父级多套了一层div） - 标题层级是否断裂（比如
h2直接跟在h4后面，中间隔着无语义div）
比任何 Lighthouse 报告都直接。一旦发现「结构树」和「视觉结构」不一致，问题八成出在
div和语义标签的嵌套关系上。 - 如果 CMS 输出不可控且无法改造，至少确保每个
- 当需要额外容器做样式隔离（如 flex 包裹、margin 控制），优先用语义中性但合法的
footer
