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