performance.memory不能直接判断DOM节点数，但usedJSHeapSize超限0.75且无大ArrayBuffer时提示DOM过载。用querySelectorAll('*').length验证，需排除动态残留、ShadowDOM等。分层预警：5000且1分钟增长500为黄；15000且内存超限0.8为红，结合监听器。
先说一个很多人容易踩坑的地方：performance.memory 这个接口看上去很有用，但不能直接拿它来判断 DOM 节点数。它返回的只是 JS 堆内存的使用情况——usedJSHeapSize、totalJSHeapSize 这些指标，并不直接暴露节点数量。不过，DOM 节点膨胀确实会显著推高 usedJSHeapSize，尤其当大量节点挂载了事件监听器、绑有内联样式或数据绑定时，内存占用就会直线上升。
那怎么利用它做预警呢？通常来说，如果 usedJSHeapSize 超过了 jsHeapSizeLimit 的 0.75 倍，而且页面里没有大型 ArrayBuffer 或 TypedArray 对象，那大概率就是 DOM 过载或监听器泄漏在作祟。这时候，可以靠 document.querySelectorAll('*').length 快速验证一下节点规模。
长期稳定更新的攒劲资源： >>>点此立即查看<<<
undefined，所以别在生产环境里通过轮询来用——每次读取本身就会触发 GC 开销。console.log(document.querySelectorAll('*').length) 看看。 包裹没有优化。
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”。做法上可以注意几点：
- 排除