先说一个很多人容易踩坑的地方：performance.memory 这个接口看上去很有用，但不能直接拿它来判断 DOM 节点数。它返回的只是 JS 堆内存的使用情况——usedJSHeapSize、totalJSHeapSize 这些指标，并不直接暴露节点数量。不过，DOM 节点膨胀确实会显著推高 usedJSHeapSize，尤其当大量节点挂载了事件监听器、绑有内联样式或数据绑定时，内存占用就会直线上升。

那怎么利用它做预警呢？通常来说，如果 usedJSHeapSize 超过了 jsHeapSizeLimit 的 0.75 倍，而且页面里没有大型 ArrayBuffer 或 TypedArray 对象，那大概率就是 DOM 过载或监听器泄漏在作祟。这时候，可以靠 document.querySelectorAll('*').length 快速验证一下节点规模。

• 这个接口在 Chrome/Edge 里能用，但 Firefox 和 Safari 会返回 undefined，所以别在生产环境里通过轮询来用——每次读取本身就会触发 GC 开销。
• 它更适合用在调试快照的场景：比如用户反馈页面卡顿的时候，随手敲个 console.log(document.querySelectorAll('*').length) 看看。
• 经验来看，超过 15000 个节点，通常意味着结构冗余了，需要检查是不是有深层嵌套的

  包裹没有优化。

document.querySelectorAll('*').length 的实际意义和陷阱

这个数值反映的是当前文档里所有元素节点的总数。但它并不直接等于“渲染开销”，而是 DOM 树复杂度的袋里指标。每个节点平均占 1–2 KB 内存，然而深层嵌套会让事件委托、样式计算、布局重排的成本指数级上升。

几个容易误判的场景值得留意：

• 动态插入但忘了清理的弹窗、提示框、日志容器，它们的节点残留会让这个数值持续增长。
• 使用 v-if 或 *ngIf 时，如果子组件实例没有正确销毁，DOM 节点虽然删了，但 JS 对象还在，querySelectorAll 里不计入它们，可内存依然在涨。
• Shadow DOM 内部的节点不会被 * 匹配到，需要单独用 shadowRoot.querySelectorAll('*') 去查。

为什么不能只看首屏 DOM 节点数

首屏可见区域可能只有 200 个节点，但后台 tab、隐藏的 display: none 区域、或者已经折叠的 accordion 面板里可能藏着 8000 多个节点——它们仍然参与样式计算、事件冒泡路径构建，并且占用着内存。

真正需要监控的是“全量活跃 DOM”。做法上可以注意几点：

• 排除