mutationobserver 在微任务队列执行，批量合并 dom 变化记录，不阻塞渲染但可能推迟 paint；观察范围过大或未及时 disconnect 会拖慢性能，需精简监听、避免重排重绘并适时断开。
MutationObserver 的执行时机和频率，直接影响页面渲染的流畅度和主线程负载。它不是“一有变化就立刻执行”，而是通过浏览器底层调度机制，在合适的时间点批量触发回调——这个机制设计得当能提升性能，配置不当反而会拖慢渲染。
它在微任务队列里执行，不阻塞渲染但会影响渲染时机
MutationObserver 的回调属于微任务（microtask），会在当前宏任务（如脚本执行、用户事件处理）结束后、下一次渲染前，集中执行。这意味着：
- 它不会像旧的 Mutation Events 那样同步打断 DOM 操作，避免了卡顿；
- 但它会抢占渲染前的空档，如果回调逻辑复杂或触发频繁，就会推迟 paint 时间；
- 同一轮事件循环中，所有已排队的 MutationObserver 回调会依次执行，直到微任务队列清空，之后才进入渲染阶段。
批量合并变化记录，减少调用开销
短时间内多次 DOM 变动（比如一次性插入 10 个节点），MutationObserver 不会为每次变动都触发一次回调，而是把它们合并成一个 mutationsList 数组传入。这带来两个实际影响：
- 减少了函数调用次数，提升了效率；
- 但也意味着你无法精确知道某次改动发生的具体时刻，只能拿到一个时间窗口内的聚合结果；
- 若需更精细的时间粒度（如计算首屏时间），需结合 performance.now() 在回调内打点，并判断首个可见内容是否已挂载。
观察范围过大会显著增加内存与 CPU 压力
启用 subtree: true 并监听 document.body 这类高活跃节点时，任何子树变更（包括框架内部操作、第三方脚本注入、甚至 CSS 动画触发的 class 切换）都会被捕捉，导致：
- MutationRecord 对象持续堆积，占用内存；
- 回调频繁执行，即使只做 console.log 也可能让 FPS 下降；
- 常见陷阱是监听整个 body 后忘记 disconnect，长期驻留造成内存泄漏。
优化建议：轻量接入 + 及时收口
真正影响渲染性能的往往不是 MutationObserver 本身，而是它的使用方式。推荐做法包括：
- 只观察必要节点，例如仅监听某个动态容器而非整个 document；
- 关闭不需要的监听项，比如不需要属性变化就设 attributes: false；
- 回调内避免重排重绘操作（如读写 offsetHeight、修改样式）；
- 完成目标后主动调用 observer.disconnect()，尤其在单页应用组件卸载时；
- 对高频变动场景加简单防抖，例如用 setTimeout 延迟汇总处理，避免每帧都响应。
