dom深度超6层时浏览器解析明显变慢，chrome devtools中node.depth≥7需优化、≥10属高危；实测5层嵌套可致低端安卓机fcp延迟20–50ms，深度≥6且子节点超200时getcomputedstyle()卡顿超80ms。
DOM深度超6层时，浏览器解析会明显变慢
Chrome DevTools 的 node.depth 值是唯一可靠指标：≥7 就该优化，≥10 已属高危。不是“看起来多”，而是浏览器每层都要创建节点、匹配结束标签、触发样式计算——5层嵌套在低端安卓机上会让首次内容绘制（FCP）延迟20–50ms。实测还发现，getComputedStyle() 在深度 ≥6 且子节点超200时，卡顿可超80ms。
querySelectorAll 深度选择器反而更危险
很多人以为 querySelectorAll('div div div div') 能安全遍历，其实它在旧版 WebKit 或 Chrome 120 以下版本中，内部仍走递归解析路径；Chrome 120+ 对超过20层的选择器会静默降级为慢路径，不报错但性能暴跌。更隐蔽的是：querySelectorAll 返回的若是实时集合（LiveNodeList），遍历中若 DOM 动态变化（比如 JS 插入新节点），可能引发重入或死循环。
用迭代 DFS 替代递归，但必须加剪枝
把递归改成 while 循环只是第一步，没剪枝照样卡死或内存溢出：
- 业务真实深度通常 ≤6 层，
if (depth > 6) continue不是保守，而是事实 - 只压入
node.nodeType === Node.ELEMENT_NODE的节点，跳过 Text/Comment - 遇到
iframe或shadowRoot默认不递归进入，除非明确需要跨上下文 - Worker 中跑解析也得设
maxDepth: 50，否则畸形 HTML（如百万注释嵌套）仍会直接终止 Worker
邮件模板和无障碍场景下，嵌套容忍度更低
Outlook（基于 Word 渲染引擎）通常在第4层 <div> 就开始丢弃子元素；而嵌套 <code>fieldset 会导致屏幕阅读器跳过中间 legend——NVDA 和 VoiceOver 只识别直接子 legend，三层嵌套时第二层逻辑分支大概率消失。此时更稳妥的做法是：
- 用平级
fieldset+aria-describedby关联上下文 - 强逻辑分支改用
radio组 + JS 控制显隐，保持 DOM 平坦 - 邮件模板中彻底放弃
div布局，改用table单元格嵌套，全平台稳定支持
div 包裹，但 CSS 选择器仍是 .page .header .nav .item a —— 浏览器仍要从每个 a 往上逐层验证父级是否存在，回溯开销一点没少。真正有效的整改，是提级样式作用域，同时用语义标签替代无意义包裹。
