Angular的变更检测——这玩意儿我研究了整整一个周末，最后发现其核心居然靠着猴子补丁（Monkey Patch）这种歪门邪道。说实话，第一次看到Zone.js的源码时，我简直想摔键盘。然而冷静下来后，不得不承认：这很脏，但确实高效。
我们先抛开那些花里胡哨的术语。你写一个Angular组件，数据一变，视图就自动更新，对吧？这背后的实时感知能力，并不是什么魔法，而是Zone.js把浏览器几乎所有的异步API都拦截了。对，是拦截。抠脚一点的解释就是：它给setTimeout、Promise、addEventListener等一堆原生函数套了一层壳，每当这些异步操作发生，它就会通知Angular：“嘿，可能有东西变了，你检查一下吧。”于是Angular就启动变更检测。
我画个图你就明白了。
这个机制其实很暴力——任何异步事件，哪怕是一个无关紧要的鼠标移动，只要触发了事件监听，就可能引发全组件树的检查。等一下，全组件树？没错，如果没做任何优化，Angular会从根组件开始，自顶向下逐一遍历所有组件的绑定值，比较新旧值是否一致。这个遍历算法是深度优先的，时间复杂度O(N)，N是绑定总数。但问题在于，哪怕只有一个小角落的数据变了，它也要把整棵树撸一遍。
几年前我待过的一个团队，在某个报表页面里塞了超过2000个组件，结果一个简单的输入框onChange，竟然阻塞UI长达300ms。我们当时用Chrome DevTools Performance面板一测，发现变更检测占了96%的时间。那可是2019年，Angular 8刚出来。后来换成OnPush策略，延迟直接降到5ms以内。
这就是第一个大坑：盲目信任默认变更检测。Angular默认的ChangeDetectionStrategy.Default会在任何异步事件后触发，哪怕你的组件输入属性是Immutable的。解决办法很简单：把组件的changeDetection设置为OnPush。但OnPush不是银弹，它只有在输入引用变化时才触发检测。所以你必须以不可变方式更新对象，或者手动注入ChangeDetectorRef调用markForCheck()。再配合detach()和detectChanges()，可以做到局部刷新。具体性能差异有多大？我做了一个简单的压测：1000个组件，每个组件显示一个随机数，每50ms更新一次最大值。在Default策略下，CPU占用率波动在80%-95%，帧率只有20fps左右；换成OnPush并用Objec.assign更新对象引用，CPU稳定在35%左右，帧率60fps。这就是实打实的提升。
不过话说回来，很多人以为是OnPush起的作用，其实本质上是我们绕过了Angular的脏检查机制。真正的脏检查发生在模板表达式的求值过程中。Angular的编译器会把你的模板编译成render函数，里面有一堆checkAndUpdateText之类的调用，比较旧值新值。这过程比React的虚拟DOM diff要重，因为React会先产生虚拟树，然后diff算法能跳过静态部分——Angular没这层，它直接在真实DOM上读值、写值。所以如果你模板里有复杂的计算，每次检测都会重新执行，疯不疯？这里引出第二个陷阱：模板中的复杂函数调用。
比如你在模板里写{{ calculateSomething(deepObject) }}，这个calculateSomething每次变更检测都会跑一遍。如果你的组件没设OnPush，那么任何全局的异步事件都会导致重新计算。我曾见过一个同事在模板里调用了三个复杂函数，里面还嵌套了for循环，直接把性能干趴了。解决方案？要么把计算结果缓存成属性，在需要更新的手动触发；要么用pipe转换——Angular的pipe默认为纯管道，只有在输入引用变化时才执行，这不正是我们想要的效果吗？用Memorization思想，将计算逻辑移到pipe里，再加一层缓存，效果拔群。
我顺便提一句，Angular 16引入的Signals其实正是为了解决这种粒度问题。Signal可以精确地告诉框架哪个数据变了，变到什么值，从而只更新受影响的DOM节点，这叫细粒度响应式。Solid.js就是靠这个火的。Angular现在也走上了这条路，目测未来会彻底替代Zone.js。不过眼下，Zone.js还是捞到爆的老功臣。
第三个陷阱，更是玩死人：依赖注入层级引发的实例爆炸或单例误用。Angular的DI系统牛逼，但很多人不理解module注入器和组件注入器的区别。一个Service如果在module的providers里声明，它就是单例；如果在Component的providers里声明，那么每个组件实例都会创建自己的一个副本。我曾追查一个bug：为什么首页的计数器老被重置？后来发现是一个全局状态Service被某个懒加载模块里的组件重新providers了，结果那个模块下面所有组件用的都是新实例，而其他地方的Inject父链拿到的还是原来的实例。这明明不是同一个Service——但名字一样，类型一样，谁能想到还有这种鬼把戏？
解决之道：用providedIn: ‘root’统一单例作用域，除非你真的需要组件级别的实例。并且，严格遵循Angular风格指南，别在共享模块里随便proivde服务，懒加载模块要小心重复注册。可以用@SkipSelf()装饰器去检查父注入器是否已经有了实例，没少人知道这玩意儿。
好了，该吐槽的吐槽了。Angular的变更检测和DI，两个核心机制，互相交织才撑起了它的企业级应用架子。虽然有些设计挺反人类的，但一旦你摸清底层的游戏规则，优化路径其实很清晰：OnPush + 纯管道 + 慎用模板函数 + 合理的作用域设计。这些最佳实践已经被各大厂踩坑验证，能让你避开至少80%的性能问题。
最后唠叨一句：别被那些说Angular太重的论调带偏。它不轻，但它重得有条理，就像重型卡车，负载再大也不会翻。反倒是那些轻量框架，不加约束的话，代码可能越写越像毛线团。反正我是怕了。
