MutationObserver 监听 childList 变化时没触发？
根本原因通常是 MutationObserver 实例没正确配置或没调用 observe()。它不会自动监听，必须显式传入目标节点和 { childList: true } 选项，且目标节点得是实际被操作的父节点——比如你往 #container 里动态加元素，就得观察 #container，而不是它的子元素或 document.body。
- 常见错误现象：
console.log完全没输出，DOM 确实变了，但回调不执行 - 必须检查：是否漏了
observer.observe(target, { childList: true })这一步（仅 new 不够） - 如果目标节点是异步插入的（如 Vue/React 渲染后才存在），需确保
observe()在节点挂载后调用 -
childList: true默认不包含后代节点变化，只管直接子节点；要监听深层嵌套，得加subtree: true
监听新增又想捕获删除节点，childList 足够吗？
足够。childList: true 本身就会同时响应 addedNodes 和 removedNodes，不需要额外配置。关键在回调里怎么区分——mutation.type === 'childList' 时，两个属性都有值，但可能一个为空数组。
- 使用场景：实时统计列表项数量、清理已卸载组件的事件监听器、做 DOM 变更审计
- 注意
removedNodes中的节点已被移出文档树，不能再调用.querySelector或读取.offsetHeight（会返回 0 或报错） - 若需保留对被删节点的引用，得在回调里立刻缓存（如
const nodes = Array.from(mutation.removedNodes)） - 不要在回调中直接修改正在被观察的节点，否则可能触发无限循环（可加防抖或用
takeRecords()手动清空队列）
为什么 MutationObserver 比 DOMNodeInserted 快还兼容性更好？
因为 DOMNodeInserted 是已废弃的 DOM2 事件，现代浏览器早就不触发了，而 MutationObserver 是 DOM4 标准，设计上就是为替代它而来——它批量派发、可暂停、不阻塞渲染，且能精准控制监听范围。
- 性能影响：同步触发的 DOM 事件（如
DOMNodeInserted）会打断渲染流程；MutationObserver回调在微任务阶段执行，更可控 - 兼容性底线：Chrome 26+、Firefox 14+、Safari 6.1+、Edge 12+；IE 完全不支持，需降级方案（如轮询
childNodes.length） - 参数差异：
MutationObserver的回调接收的是MutationRecord[]数组，每个 record 包含type、addedNodes、removedNodes、previousSibling等字段，比事件对象信息更结构化
监听到变化后，如何安全地操作新节点？
新节点虽已插入，但不一定完成样式计算或布局，尤其涉及 offsetTop、getBoundingClientRect() 时容易拿错值。稳妥做法是把操作逻辑放进 requestAnimationFrame 或 setTimeout(..., 0)。
立即学习“前端免费学习笔记（深入）”；
- 常见错误现象：取到
offsetHeight === 0，或 CSS 动画没触发 - 推荐写法：
observer.observe(target, { childList: true }); const callback = mutations => { mutations.forEach(mutation => { mutation.addedNodes.forEach(node => { if (node.nodeType === Node.ELEMENT_NODE) { requestAnimationFrame(() => { // 此时 layout 已更新，可安全读取尺寸 console.log(node.offsetHeight); }); } }); }); }; - 避免在回调里频繁调用
querySelectorAll遍历整个容器——只处理addedNodes里的节点即可，效率高得多 - 如果新节点含 script 标签，
MutationObserver不会执行它；需手动eval或创建新 script 元素（注意 CSP 限制）
MutationObserver 单打独斗。 
