Web组件中observedAttributes()与MutationObserver的使用差异

• 触发机制本质不同：observedAttributes搭配的attributeChangedCallback属于自定义元素原生生命周期的一部分，是同步执行的——属性值在DOM上刚更新完，回调会立刻在当前同步任务里触发，不会有延迟，也不会被其他逻辑插队。而MutationObserver的回调是微任务异步批处理的，你在一段同步代码里连续改10次属性，它不会触发10次，会等当前所有同步代码跑完，把所有变更攒成一批再统一执行回调，你拿不到变更过程中的即时中间状态。
• 作用边界完全不同：observedAttributes是定义在自定义元素类上的静态配置，从组件代码写完的那一刻就定了：只能监听当前组件自身的属性，既不能动态增删要监听的属性列表，也管不了子元素、其他无关元素的变更。MutationObserver没有这个绑定限制，你可以监听任意DOM节点，开了subtree配置还能盯整个子树的所有变更，监听的属性列表、监听的变更类型（属性/子节点/文本）都能动态调整，灵活度高很多。
• 性能开销基线不同：原生生命周期回调是浏览器引擎内置的逻辑，没有额外的运行时开销——只有你列在observedAttributes里的属性变更时，引擎才会触发回调，不在列表里的属性改了引擎根本不会做额外检查。MutationObserver是独立的通用API，哪怕只监听一个属性，也需要维护独立的观察者实例、走变更记录队列的批处理逻辑，监听范围越大（比如监听整棵DOM子树），性能开销越高。
• 回调返回的信息不同：attributeChangedCallback的参数非常直接，只给你返回变更的属性名、旧值、新值三个核心信息，没有冗余内容。MutationObserver会返回完整的MutationRecord数组，除了属性新旧值之外，还能拿到具体是哪个节点发生的变更、变更类型，甚至会记录连续多次修改的轨迹（没被批处理合并的前提下）。

• 优先选原生observedAttributes方案的场景：
  开发自定义元素自身的核心响应式逻辑时，这是首选方案。比如组件内置的disabled、size、theme这类声明式属性，需要属性一变就立刻同步更新组件内部状态、DOM结构或者样式——这种写法逻辑完全内聚在组件类里，其他人读代码的时候看静态observedAttributes的返回值，一眼就能知道哪些属性是组件响应式处理的，没有额外依赖，性能也最好。
  举个最常见的例子：你封装一个自定义按钮组件，type属性从primary改成danger的时候需要立刻切换按钮的样式类，直接写在attributeChangedCallback里就行，完全没必要引入MutationObserver。
• 优先选MutationObserver方案的场景：
  • 你需要在组件外部监听DOM属性变化，比如写通用的全局指令、埋点脚本、第三方扩展，要监听的元素不是你自己封装的自定义组件，你根本没法去改别人的元素类定义加observedAttributes配置，这时候只能用MutationObserver。
  • 你需要的监听能力超出了原生生命周期的范围：比如要动态调整监听的属性列表、要同时监听子节点的增删/文本内容变化、要监听整个子树里所有元素的属性变更，这些需求原生生命周期根本覆盖不了。
  • 你不需要对每次属性变更做即时响应，批量处理反而能提升性能的场景：比如你监听一个容器的所有配置类data-*属性，不管用户一次改多少个属性，你只需要最后统一重新渲染一次容器就行，这时候MutationObserver的批处理机制反而能帮你避免重复执行渲染逻辑，减少性能浪费。

踩坑提醒：别图灵活在自定义组件内部全用MutationObserver替代原生生命周期，异步批处理的特性很容易导致状态不一致——比如你连续修改两个关联属性，第一次修改完组件触发了重渲染，这时候MutationObserver的回调还没排队执行，渲染逻辑拿到的还是旧的属性值，很容易出现很难排查的状态错位bug。

内容的提问来源于stack exchange，提问作者David Min