mutationobserver 回调在微任务队列执行，非立即触发，易引发dom状态错位、布局读取失真、无限循环修复三类陷阱；需用promise微任务延迟读布局、监听稳定父容器、通过disconnect或标志位阻断递归。
MutationObserver 的回调在微任务队列中执行，不是“一变就立刻运行”，而是等当前宏任务（比如点击事件、脚本同步执行）结束后，统一批量处理。这个时机看似合理，却容易引发三类典型陷阱：DOM 状态错位、布局读取失真、无限循环修复。
回调里拿不到最新渲染状态
很多人在 MutationObserver 回调里直接调用 getBoundingClientRect() 或 offsetHeight，结果拿到的是旧尺寸。因为微任务虽快，但仍在浏览器渲染之前——此时样式已更新、DOM 已插入，但布局尚未计算。
正确做法是再套一层微任务：
- 用
Promise.resolve().then(() => { /* 读布局 */ })把读取逻辑推到渲染前最后一刻 - 避免在回调里做依赖视觉反馈的操作（如弹窗定位、滚动锚点），除非你确认不需要精确像素值
误把框架重渲染当“新节点”处理
React/Vue 组件更新时，常销毁旧节点、挂载新节点。如果你监听的是被替换的子元素本身（比如 document.querySelector('.item')），observer 会因 target 消失而自动停止触发；但若监听父容器，又可能把框架内部重建当成恶意插入，反复移除合法节点。
应对方式：
- 监听稳定父容器（如
id="list-container"），不盯动态生成的子节点 - 用
mutation.addedNodes中节点的node.isConnected判断是否真已挂载 - 对关键节点加
data-observed="true"标记，过滤掉框架临时占位节点
修复操作触发新一轮监听，形成死循环
比如监听 class 变化，发现 class="hidden" 就把它改成 class="visible"——这个属性修改本身又会触发下一轮回调，没控制就会无限递归。
必须主动切断链路：
- 修复前先
observer.disconnect() - 操作完成后再
observer.observe(...)重新监听 - 或用标志位（如
isFixing = true）跳过修复期间的回调
它不是事件监听器，而是微任务调度器。理解这点，才能避开卡顿、错判和内存泄漏。
