DOM深度超过6层会显著拖慢getComputedStyle等API，因样式计算和选择器回溯呈指数级加重，须用Chrome DevTools查看node.depth值确认真实渲染树深度并压平至6层内。
DOM深度超过6层时getComputedStyle会明显变慢
浏览器对深层DOM的样式计算不是线性增长，而是指数级加重。当document.querySelector('.a .b .c .d')匹配路径里父链超过6层，失败时回溯成本陡增；getComputedStyle调用耗时可能翻倍，尤其在动画帧中触发会直接卡顿。
- 真实渲染树深度 ≠ 源码缩进——用 Chrome DevTools 右键节点 → Show DOM properties 查看
depth值，超过6必须干预 - SSR或框架注入的 wrapper（如
<div class="page"><div class="main">）虽不可见，仍参与样式继承和布局上下文创建 -
<table>类结构容易隐式加层：没写<tbody>？DOM里自动补上；写了但放错位置？浏览器会挪动它——这说明你写的结构和实际渲染树已脱节
用CSS替代冗余包裹层，而不是删标签
压平DOM不是靠删
，而是把本该由嵌套表达的视觉层级，交给
gap、padding、::before/::after、grid-template-areas来承担。
- 图标+文字组合：
<div><div><svg></svg></div><div>文本</div></div>→ 改用display: flex+ 内联文本 - 分隔线：
<div class="divider"></div>或<hr>→ 改用border-bottom或伪元素::after - 卡片组件：
card-wrapper → card-inner → card-body → card-content多数可合并为单层，用padding和gap控制内间距 - 表单控件：
<div><div><div><input></div></div></div>→ 用语义化<label class="input-group"><input></label>即可
验证是否真降了深度，别信源码缩进
HTML源码看着扁平，不代表渲染树真的浅。有些框架在服务端注入不可见 wrapper，它们不占视觉空间，却实实在在增加 DOM 深度和样式计算负担。
- Performance 面板录制加载过程，重点观察 Layout 阶段耗时是否下降——这才是深度优化的真实反馈信号
- 避免用
document.querySelectorAll('*').length估算“节点总数”，它和性能关系极弱；真正关键的是document.body.children[0].children[0].children[0]这类链式访问是否存在 - 自动化测试中验证结构，优先用
Puppeteer或Playwright加载真实页面后读取document.body.innerHTML，而非依赖 cheerio 等服务端解析器结果
DOM变浅后JS操作的实际收益点在哪
结构变浅不会让 JS 执行更快，但它会让每次触达 DOM 的开销大幅降低——这才是前端性能瓶颈常被误判的地方。
立即学习“前端免费学习笔记（深入）”；
-
document.querySelector('.user-card .avatar img')从4层降到2层，匹配速度提升不止一倍，尤其在事件委托中冒泡路径缩短，响应更及时 - 批量插入时，
DocumentFragment不再需要模拟深层父链，创建和挂载更快 - 读取
offsetTop或getBoundingClientRect()时，强制同步布局（layout thrashing）风险显著下降，因为父链短、回溯快 - 某些场景下，
innerHTML替换整块内容反而比逐个操作子节点更轻量——前提是父容器本身足够浅
