嵌套过深的<div>会拖慢渲染和可访问性，因浏览器解析、样式计算、布局重排成本随深度非线性上升，且屏幕阅读器易迷失上下文而跳过关键语义信息；根本原因是以<div>替代原生语义标签（如<nav><ul>），应优先用<header><main><section>等承担结构与语义职责。
为什么嵌套过深的 <div> 会拖慢渲染和可访问性
DOM 节点层级太深（比如连续 5–6 层 <div> 套娃）不只是看着乱。浏览器解析、样式计算、布局重排的成本会随深度非线性上升；屏幕阅读器读取时也容易迷失上下文，跳过关键语义信息。
根本问题不是“用了 <div>”，而是用 <div> 替代了本该承担语义的原生元素——比如把导航栏写成 <div class="nav"><div><div><ul>...，而不是直接用 <nav> 包裹 <ul>。
- 优先用语义化标签替代无意义容器：
<header>、<main>、<section>、<article>、<aside>、<footer>都自带隐含结构层级，不需要额外<div>打包 - 避免为纯样式目的包裹：如果只是为了加 margin 或 background，直接给目标元素加 class，别为了“方便定位”多套一层
<div> - 检查 CSS 选择器是否在倒逼 HTML 嵌套：比如写
.sidebar .content .title，往往意味着 HTML 里真塞了三层<div>—— 这时应简化选择器，或改用 BEM 类名（如sidebar__title）解耦结构依赖
<section> 和 <div> 的边界在哪
<section> 不是“视觉分块”的同义词。它代表一个有独立标题的主题内容块（通常含 <h2>–<h6>），比如“用户评论区”“相关文章推荐”。没标题？大概率该用 <div>。
常见误用：
❌ <section class="card"><div class="card-body">...（卡片只是 UI 组件，无独立主题）
✅ <div class="card"><div class="card-body">...
- 能被单独引用、编号、出现在文档大纲里的内容 → 用
<section> - 仅用于样式隔离、JS 操作钩子、响应式断点控制 → 用
<div> - 同一页面中多个
<section>应有逻辑并列关系，而非父子嵌套（嵌套<section>容易让大纲混乱）
CSS Grid / Flexbox 如何减少对包装容器的依赖
过去靠多层 <div> 实现布局对齐，现在可以直接让语义元素自身参与布局流。例如页脚固定底端，不用 <div class="wrapper"><div class="content">...</div><div class="footer">...</div></div>，而用：
立即学习“前端免费学习笔记（深入）”；
<body>
<main>...</main>
<footer>...</footer>
</body>
<style>
body {
display: grid;
grid-template-rows: 1fr auto;
min-height: 100vh;
}
</style>
- 让
<header>、<main>、<footer>直接成为 Grid 容器子项，省掉 wrapper<div> - 卡片列表用
display: flex或display: grid直接作用于<article>父容器，不再需要<div class="cards">中间层 - 注意：Grid/Flex 的父容器仍需存在，但它可以就是语义元素本身（如
<section>），而非无意义<div>
用开发者工具快速识别冗余 DOM 层级
打开 Chrome DevTools → Elements 面板，按 Ctrl+Shift+C 选中目标区域，观察右侧 DOM 树是否出现连续 3 层以上无语义标签（全是 <div> 或 <span>）。重点看：
- 是否有重复 class 名（如
container套container） - 是否有空
<div>（只含空格或注释） - 是否每个
<div>都有明确职责（JS hook？BEM modifier？还是纯装饰？）
修复时别一次性全删——先删最外层无用 <div>，刷新看样式/脚本是否崩；再逐层向上验证。很多“删不掉”的容器，其实是 CSS 里写了 .parent > .child 这种强耦合选择器，这时要同步改 CSS，而不是妥协留着 DOM。
真正难的不是找到哪层该删，而是判断删完后语义是否完整、焦点顺序是否错乱、屏幕阅读器是否还能正确播报结构——这些没法靠自动工具发现，得手动测试。
