不能只靠 performance.getEntriesByType('resource') 监测 DOM 膨胀，因它仅记录外部资源加载，无法捕获 JS 动态插入节点；需在 DOMContentLoaded、navigation/paint 回调（校验 readyState 和 body）、路由变更后三阶段采样，并用 childNodes.length+递归（深度≤4）替代 querySelectorAll，阈值过滤后 beacon 上报。
不能只靠 performance.getEntriesByType('resource') 监测 DOM 膨胀，它根本看不到 JS 动态插入的节点。
为什么 DOM 节点异常总漏报？
很多团队把 performance.getEntriesByType('resource') 当成万能监控入口，结果线上页面堆了 5000+ div 却毫无告警。原因很直接：这个 API 只记录外部资源加载事件（JS/CSS/图片），对 document.createElement、innerHTML +=、React/Vue 渲染等纯 JS 操作完全无感。
更隐蔽的问题是时机错配：
-
window.onload触发时，SPA 的路由组件可能还没挂载，mounted或useEffect还没执行 - 仅监听
DOMContentLoaded，只能捕获初始 HTML 结构，漏掉所有 JS 动态渲染内容 - 用
PerformanceObserver监听navigation类型，拿到的是domComplete，但此时首屏关键节点未必已就位
三个必须覆盖的采样时机
单一时机必然失真，必须在静态解析、JS 渲染、路由更新三阶段主动触发节点统计：
-
DOMContentLoaded后立即执行：获取初始 DOM 树规模，作为基线参考 - 用
PerformanceObserver监听navigation和paint类型，在回调中加双重校验 ——document.readyState === 'complete'且document.body存在后再采样 - 对 SPA 应用，监听
history.pushState或框架路由钩子（如router.afterEach），路由变更后延迟100ms再采样，避开组件mounted前的竞态窗口
怎么采样才不卡主线程？
直接用 document.querySelectorAll('*').length 在节点超 10k 时会触发强制重排，尤其在低端 Android 上明显卡顿。实际落地要绕开这些坑：
- 别在
requestAnimationFrame回调里执行统计逻辑，它会让计算参与帧渲染流水线 - 改用
document.body?.childNodes.length+ 递归计数（深度限制 ≤ 4），比通配符查询快 3–5 倍 - 上报前加阈值过滤：
if (nodeCount > 1500) sendToMonitoring({ metric: 'dom_node_count', value: nodeCount })，避免高频小数值刷屏 - 禁止在
PerformanceObserver回调中直接发网络请求，统一用navigator.sendBeacon()异步保底
容易被忽略的边界情况
真实业务里，以下三点常让节点数告警失效：
- 第三方组件库（比如某些 UI 组件）内部大量使用
cloneNode或insertAdjacentHTML，但没触发任何resource加载，监控完全盲区 - 服务端渲染（SSR）+ 客户端水合（hydration）场景下，初始节点数和水合后节点数差异巨大，需区分采集上下文
- 动态
iframe插入后，其子文档的节点不计入父文档document统计范围，需单独监听iframe.contentDocument
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
