DOM深度超6层会直接拖慢layout和getComputedStyle，实测低端安卓机上深度从5升到7时首屏layout耗时从80ms跳至320ms；浏览器对>6层节点树放弃部分优化，每次样式变更触发整棵子树重算。
DOM深度超6层会直接拖慢layout和getComputedStyle
不是“可能变慢”，是实测在低端安卓机上，深度从5升到7，首屏layout耗时就从80ms跳到320ms。浏览器layout engine对>6层的节点树会放弃部分优化，每次样式变更都触发整棵子树重算。关键指标是document.querySelectorAll('*').length和单个节点的depth字段——后者在Chrome DevTools右键节点→Show DOM properties里直接可见。
- SPA首屏硬性阈值设为500个节点，整页上限2000，CI里必须断言：
page.evaluate(() => document.querySelectorAll('*').length) > 2000 -
depth > 6的节点几乎都来自无class、无事件、无样式的纯套，比如CMS生成的<div class="wrapper"><div class="container"><div class="row"><div class="col">- 别信W3C Validator——它只校验语法合法，不报深度问题；用DevTools的Rendering面板看真实渲染树
用DOMParser + 迭代遍历替代正则和递归检测
正则匹配
<div><div><div>完全不可靠，<script>console.log('</div>');</script>这种场景直接崩。而DOMParser能自动修复错位闭合、引号不匹配等问题，才是真实解析起点。- 生产环境禁用递归函数检测深度（如
getDepth(node)），改用显式栈迭代：const stack = [root]; while (stack.length) { const node = stack.pop(); if (node.children.length) stack.push(...node.children); } - 富文本、模板引擎输出、第三方SDK注入的DOM，必须走预检中间件，阈值设为
maxDepth = 100，超限直接抛错阻断 - 避免
querySelectorAll('*').forEach()——这等于把整棵树塞进调用栈，Array.from()转数组再遍历也不安全
replaceChildren()不是语法糖，而是引用切断机制
replaceChildren()比innerHTML = ''多做的事，是同步销毁旧子节点的样式计算上下文和parentNode引用链。深层DOM里，只要JS变量还拿着某个节点，整条祖先链就卡在内存里。- 错误写法：
el.replaceChildren(htmlString)→ 报错，replaceChildren()只接受Node或DOMString，但字符串不会自动解析 - 仍用
items.map(i => <div>${i}</div>).join('')拼接再传入 → 白费，等价于又走了一遍innerHTML路径 - 正确姿势：每个子节点都用
document.createElement()显式创建，再统一传入；兼容IE需前置检测：if ('replaceChildren' in Element.prototype)
删掉一个没用的
比压缩10KB JS更有效过度包装不是风格问题，是硬性性能瓶颈：触发DOM构建延迟、CSS匹配爆炸、事件冒泡变慢、内存占用翻倍。很多“看起来需要包裹”的场景，CSS完全能接管，零节点开销。
立即学习“前端免费学习笔记（深入）”；
- 分隔线、角标、小图标：用
::before/::after伪元素，不用<div class="divider"> - 间距控制：优先用
display: grid或flex的gap属性，而不是塞<div style="height: 16px"></div> - 外边框模拟：用
outline+outline-offset，比套一层<div>更轻量 - 后台系统里，
class含wrap、container、inner的节点，80%可删；重点关注document.querySelectorAll('div:not([class]):not([id])')揪出纯包裹层
