html嵌套错误会触发浏览器自动修正dom结构，导致重排范围扩大、祖先链被迫参与布局、样式继承断裂及js元素查找失败。
<div> 嵌套本身不会报错，但多数“布局失效”“样式不生效”“JS 找不到元素”的问题，根源不在怎么嵌，而在为什么嵌——每层 <code><div> 必须有明确的职责，否则就是技术债。
<h3>什么时候必须用语义标签替代 <code><div> 嵌套
<p>纯视觉分组 ≠ 逻辑分组。比如导航栏写成 <code><div class="nav">，屏幕阅读器读不出它是导航；换成 <code><nav></nav> 就能被识别为导航区域。
-
<main></main>不能套在<section></section>或<div> 里——W3C 明确禁止，否则其“唯一性”语义失效 <li> <code><p></p>、<h1></h1>～<h6></h6>、<dt></dt>这些标签内**不允许放<div>**，浏览器会自动修复 DOM，把 <code><div> 挤到外面，导致结构错乱 <li> <code><ul></ul>和<nav></nav>是协作关系，不是父子关系：导航菜单内部用<ul></ul>是推荐做法，但把友情链接列表包进<nav></nav>就可能误标语义 - CSS 选择器越来越长（如
.wrapper .container .main .content .item），改一个样式要翻三屏 - JS 用
document.querySelector找元素总返回null，其实是路径里某层<div> 被意外删了或拼错了类名 <li>服务端渲染场景下，HTML 字节数增加，首屏解析时间微升（可测但常被忽略）</li> <p>真正该警惕的不是“能不能嵌”，而是“值不值得嵌”：如果某层 <code><div> 既没 <code>class、也没id、还没内联样式，那它大概率是冗余的。flex/grid 容器里嵌套
<div> 导致布局失效 <p>当父 <code><div> 设了 <code>display: flex，它的**直接子元素**才成为 flex item；中间多套一层<div>，那这层就变成 item，而你真正想排布的元素成了“item 的子元素”，不再受 flex 控制。 <ul> <li>错误写法：<code><div class="flex"><div><div class="target">内容</div></div></div>→.target不参与 flex 排列 - 修复方式：删掉冗余包裹层，或把
display: flex移到更内层容器上 - 调试技巧：在 DevTools 中选中目标元素，看右侧面板 “Computed” 标签页里
display最终值是否符合预期；若显示block，说明被某条规则重置了 - 关键原因：
#div3无非浮动内容、无显式高度、无清除机制 - 稳妥解法：用伪元素清除浮动，而非依赖
overflow: hidden（后者在需滚动或下拉菜单时可能裁剪内容） - 正确 HTML 结构应先闭合父容器再插入子元素，避免把纯文本（如 "test 3"）混在浮动子元素之间
嵌套超过 3 层时的典型问题与应对
深层嵌套往往不是布局需要，而是结构没想清或 CSS 没抽离好。常见现象包括：
浮动导致父容器塌陷时的嵌套修正
当一个容器（如 #div3）仅包含设置了 float: left 的子元素（如 #div4、#div5），该容器会发生高度塌陷（collapsing）——即其计算高度变为 0，导致背景色、边框等失效，看起来“消失了”，而浮动子元素则与父容器中的文本内容发生环绕式重叠。
真正难的不是怎么嵌套，而是每次敲下 <div> 时，能不能立刻说出它存在的唯一理由：是为 CSS 提供作用域？为 JS 提供挂载点？还是为语义留个 hook？如果答案模糊，那这层 <code><div> 很可能正在悄悄拖慢你的迭代节奏。</div>
