DOM树深度超6层时getComputedStyle突然变慢，因浏览器需向上逐层匹配祖先CSS选择器，导致计算路径线性增长；深度从4到8耗时翻倍，到12层低端安卓机单次调用卡顿超80ms。
DOM树深度超6层时getComputedStyle为什么突然变慢
不是“变慢一点”，是计算路径线性增长——浏览器查每个元素样式，得一路向上匹配祖先节点的CSS选择器。深度从4到8，getComputedStyle()耗时直接翻倍；到12层，低端安卓机单次调用卡顿超80ms。
常见错误现象：body > div > div > div > .item这类强嵌套选择器，在深层DOM里匹配效率极低；用querySelectorAll('.item')查100个节点时，DOM深度每+1，总耗时+12%左右。
- 用Chrome DevTools → Elements面板右键任意节点 → “Show DOM properties”，看
node.depth值，超过6就要警惕 - 别写
div div div h2，改用.card .title——后者靠类名直取，不依赖结构深度 - 语义化标签如
section、article、nav不增加渲染开销，还能缩短选择器路径
重排(reflow)在深层DOM里为什么代价指数级上升
改一个.list的高度，实际要重算它所有.item及其子节点的布局，而不是只算.list自己。父节点尺寸变更会逐层向下传导，中间参与计算的节点数随深度激增。
使用场景很典型：SPA路由切换后动态插入内容、表格行内嵌编辑区、折叠面板展开时批量渲染子项——这些操作若发生在深度≥8的DOM里，极易肉眼可见卡顿。
立即学习“前端免费学习笔记（深入）”；
- 避免在循环里反复操作深层节点，优先用
DocumentFragment或一次性写入innerHTML - 对频繁展开/收起的模块，用
display: none隐藏整块，别只藏最外层容器——visibility: hidden仍保留布局计算 - 高频操作前务必缓存引用：
const items = document.querySelectorAll('.item');，后续遍历items而非重复查询
哪些JS操作会强制触发深层DOM同步重排
不是所有DOM读写都一样。只要访问以下任一属性，浏览器就必须立刻清空待处理队列、同步执行重排，哪怕你刚写了10行修改代码还没来得及合并。
典型触发点包括：offsetTop、offsetWidth、scrollTop、clientHeight、getComputedStyle()、getBoundingClientRect()。
for (let i = 0; i 在深度10的DOM里比深度3慢3.7倍，且强制100次重排- 不要在循环中混用读写：
el[i].style.left = x + 'px'; console.log(el[i].offsetLeft);——第二句立刻打断优化 - 把读操作集中前置，写操作集中后置；中间穿插的读，必须加注释说明不可省略
大屏表格或日志流渲染时DOM复用池怎么避坑
直接document.createElement('tr')是性能黑洞——每次调用都触发内存分配 + 样式树挂载 + layout → paint 全链路。复用池绕过这一整套开销，但错一步就错全盘。
核心陷阱不在数据量，而在让浏览器把所有节点都当成“需要立即参与渲染”的对象对待。
-
recover()必须清空textContent和innerHTML，否则旧数据残留导致错行或样式错乱 - 不在
createFn里绑定事件监听器；应在取出后按需绑定，回收前用removeEventListener解绑 - 池大小设为可视区域行数 × 2～3（如视口显示20行，池配40～60个
tr），过大拖慢GC - 带
dataset或内联样式的td，回收时也要重置node.dataset.key = ''和node.style.cssText = ''
固定行高是虚拟滚动的前提；动态行高会让Math.floor(scrollTop / rowHeight)失效，工业级方案要么预估平均高度并缓存，要么强制统一——后者在大屏监控中更可控。
