真正影响性能的是监听范围过宽和配置过松：subtree: true 导致浏览器递归扫描子树、生成大量 mutationrecord，增大内存占用并拖慢回调处理；应精简 attributefilter、避免滥用 subtree 与 attributes 组合，并在组件卸载时及时 disconnect。
监听深度 DOM 时，微任务开销本身不增加，但触发频率和记录体积会显著上升——真正影响性能的不是微任务调度机制，而是你观察范围太宽、配置太松导致浏览器要收集和打包更多变动。
subtree: true 是开销主因，不是微任务本身
微任务队列的执行成本是固定的：一次回调、一次函数调用、一次 records 数组遍历。但开启 subtree: true 后，浏览器需递归扫描整个子树中所有节点的变动，哪怕只是 body 下某个广告脚本插入一个 div，也会被完整捕获并计入 records。这带来两个实际负担：
- 内存占用变大：每条 MutationRecord 包含 addedNodes、removedNodes、target、type 等字段，深层监听下 records 数组可能达数百项
- 回调处理变慢：你写的回调逻辑（比如遍历每个 addedNode 查 class）要处理的数据量翻了数倍
attributeFilter 和 childList 配合能大幅减负
不加过滤的 attributes: true + subtree: true 相当于让浏览器“盯住整棵树每个节点的每个属性”，哪怕只是第三方 SDK 频繁切换 style.display 或 class，都会生成大量无意义记录。建议：
- 只监听真实需要的属性：
attributeFilter: ['data-status', 'data-loaded', 'aria-hidden'] - 若只关心结构变化（如组件挂载），关闭 attributes 和 characterData，仅保留
childList: true - 避免同时开 subtree 和 attributes，除非明确需要——多数场景只需监听目标容器直系子节点增删
高频变动下，微任务不会堆积，但你的逻辑可能卡主线程
MutationObserver 的微任务调度很稳：100 次 setAttribute 只触发 1 次回调，records 数组包含全部 100 条记录。问题出在回调里——如果你对每条 record 都做 node.querySelector('.btn').addEventListener()，等于手动执行了 100 次 DOM 查询和事件绑定。正确做法是：
- 先用 Set 去重所有新增节点：
const allAdded = [...new Set(mutations.flatMap(m => Array.from(m.addedNodes)))] - 批量处理：
allAdded.forEach(initComponent)，而不是嵌套在 mutations 循环里 - 对耗时操作延后：
requestIdleCallback(() => processRecords(records))
及时 disconnect 才能真正释放资源
微任务开销可接受，但长期挂着一个监听 body 或 document 的 observer，会持续接收所有页面级变动（包括路由切换、弹窗打开、广告注入），即使回调为空，浏览器仍要维护内部变动队列和匹配逻辑。务必做到：
- 组件卸载前调用
observer.disconnect() - 不用重复 new Observer，复用实例并调用
observe(target, config)切换目标 - 临时停用可用
takeRecords()清空队列，避免积压
