此答案适用于大型页面和复杂页面。
特别是如果在页面开始加载之前附加了观察者（即
document_start/
document-start在Chrome扩展程序/
WebExtensions /userscripts中，或者仅在内部的常规同步页面脚本中
<head>），但在庞大的动态更新页面上（例如，在GitHub上进行比较）。如果页面是大而复杂的未优化MutationObserver回调可以添加几秒钟的网页加载时间1，2。大多数示例和现有库都没有考虑到这种情况，而是提供了美观，易用但缓慢的js代码。
MutationObserver回调是作为微任务执行的，该微任务阻止DOM的进一步处理，并且每秒可以在复杂页面上触发数百或数千次。
始终使用devtools分析器，并尝试使您的观察者回调所消耗的时间少于页面加载期间消耗的总CPU时间的1％。
通过访问offsetTop和类似属性避免触发强制同步布局
避免使用复杂的DOM框架/库（如jQuery），更喜欢使用本机DOM。
观察属性时，请使用中的
attributeFilter: ['attr1', 'attr2']
选项.observe()
。只要有可能，请非递归地观察直系父母（
subtree: false
）。
例如，通过document
递归地观察等待父元素，在成功时断开观察者的连接，在此容器元素上附加一个新的非递归对象是有意义的。当仅等待具有
id
属性的一个元素时，请使用快速的速度，getElementById
而不是 枚举mutations
数组（它可能有成千上万个条目）：example。例如，如果所需元素在页面上相对较少（例如
iframe
或object
），则使用getElementsByTagName
和返回的实时HTMLCollectiongetElementsByClassName
并重新检查所有元素，而不是枚举mutations
如果它具有100个以上的元素。避免使用
querySelector
，尤其是极慢的速度querySelectorAll
。如果
querySelectorAll
在MutationObserver回调中绝对不可避免，请首先执行querySelector
检查，如果成功，则继续进行querySelectorAll
。平均而言，这样的组合会快很多。如果定位到非出血边缘浏览器，请不要使用需要回调的内置Array方法（如forEach，filter等），因为在Chrome的V8中，与经典
for (var i=0 ....)
循环相比，这些函数的调用总是昂贵的（慢10到100倍） ，但V8团队正在研究[2017]），并且MutationObserver回调可能每秒触发100次，addedNodes
在复杂的现代页面上每批次的突变都有数十，数百或数千个。
数组内置的内联不是通用的，通常发生在类似基准的原始代码中。在现实世界中，MutationObserver的活动具有间歇性的峰值（例如每秒1-1000个节点每秒报告100次），并且回调从未如此简单，
returnx * x因此无法检测到代码“热”得足以内联/优化。
但是由lodash或类似的快速库支持的替代功能枚举是可以的。从2018年开始，Chrome和底层V8将内联标准数组内置方法。
如果定位不流血的边缘浏览器，不要使用慢速ES2015圈像
for (let v of something)
MutationObserver回调里面，除非你transpile从而使得到的代码的运行速度是经典的for
循环。如果目标是改变页面的外观，并且您有一种可靠，快速的方法来告知所添加的元素不在页面的可见部分之外，请断开观察者的连接，并通过以下方式安排整个页面的重新检查和重新处理
setTimeout(fn,0)
：解析/布局活动的初始爆发完成，引擎可以“呼吸”，甚至可能需要一秒钟。然后，您可以使用例如requestAnimationframe显着地处理页面。
回到问题：
观察一个非常确定的容器
ul#my-list，看是否<li>有附加的容器。
由于
li是直接子节点，并且我们正在寻找添加的节点， 因此唯一需要的选项 是
childList: true（请参阅上面的建议2）。
new MutationObserver(function(mutations, observer) { // Do something here // Stop observing if needed: observer.disconnect();}).observe(document.querySelector('ul#my-list'), {childList: true});
