为什么 MutationObserver 完全没触发？
最常见原因是观察目标节点没真正插入 DOM，或 observer 实例创建后没调用 observe()。比如在 Vue/React 组件中，你可能在 mounted 或 useEffect 里新建了 MutationObserver，但传入的 target 是个还没挂载到 document 的空引用（null 或 undefined），或者忘了调用 observer.observe(target, options)。
检查方法很简单：在调用前加一行 console.log(target, target?.nodeType)，确保它是个有效的 Element 节点（nodeType === 1）。
- target 必须是已存在于 DOM 树中的节点；动态创建的节点要等
appendChild或insertAdjacentElement完成后再 observe - 不能对
document或document.body直接 observe —— 某些浏览器（如旧版 Safari）对根级观察支持不稳定，优先选具体容器元素 -
MutationObserver不监听 CSS 属性、style变化或自定义属性（data-*）的值变更，只响应 DOM 结构和属性的显式修改
MutationObserver 对属性变化不响应？
默认情况下，MutationObserver 不监听任何变化。必须显式开启对应选项：attributes: true 才能捕获 setAttribute、removeAttribute 等操作；若还需知道是哪个属性变，得加上 attributeFilter: ['class', 'id'] 或留空表示监听所有属性。
注意：仅设置 attributes: true 不会监听子元素的属性变化，除非同时设 subtree: true —— 但这样开销大，容易误触发。推荐聚焦具体父容器 + 明确 attributeFilter。
立即学习“前端免费学习笔记（深入）”；
- 修改
style内联样式（如el.style.color = 'red'）属于属性变更，可被监听；但通过 class 切换触发的样式变化不算 -
value属性在 input 元素上通常不会被MutationObserver捕获（因为用户输入走的是事件流，不是 DOM 属性写入），要用input或change事件 - 使用
attributeOldValue: true才能在回调中拿到变更前的值，否则mutation.oldValue是undefined
异步更新后 DOM 已变，但 MutationObserver 还是没反应？
典型场景是框架（如 React、Vue）批量更新 DOM 后，MutationObserver 回调延迟执行，但你手动查 DOM 发现内容已经存在——这其实是预期行为：MutationObserver 的回调在 microtask 队列中执行，晚于同步代码，但早于 setTimeout。问题往往出在「你监听的节点被框架替换了」。
比如 Vue 的 v-if 切换、React 的 key 变更，会导致旧节点被移除、新节点重建。此时 observer 会自动断连（disconnect() 不会自动调用，但 target 消失后不再触发）。解决思路不是重连 observer，而是监听更稳定的父容器，并用 childList: true + subtree: true 捕获新增节点。
- 避免监听会被框架完全替换的节点（如整个组件根元素），改监听其稳定父级（如
#app或某个不变的 wrapper） -
childList: true只监听直接子节点增删；subtree: true才能穿透到深层，但性能敏感区域慎用 - 如果只关心某类元素出现（如
.toast），可在回调里过滤mutation.addedNodes，再用node.matches('.toast')判断
兼容性与内存泄漏风险
MutationObserver 在 IE 中完全不可用，Chrome 26+/Firefox 14+/Safari 6+ 支持良好。但真正容易出问题的是忘记清理：observer 实例不会随 DOM 节点自动销毁，若页面长期存在、频繁创建 observer 却不 disconnect()，会持续持有节点引用，阻止 GC，尤其在单页应用路由切换时很危险。
- 务必在组件卸载、模块销毁时调用
observer.disconnect()；React 可在useEffect返回函数中做，Vue 可在beforeUnmount钩子中做 - 不要在循环或高频事件（如
scroll）中反复 newMutationObserver，复用实例更安全 - 观察大量节点或深度 subtree 时，回调内避免做重计算或 DOM 查询；可用
requestIdleCallback包裹耗时逻辑
真正难处理的永远不是“怎么监听”，而是“监听谁”和“什么时候停”。DOM 动态性越强，越要收缩观察范围、绑定生命周期、提前预判节点命运。
