为何在ngOnChanges中调用detectChanges前先分离ChangeDetectorRef？

适用场景 #

• 性能敏感的纯输入驱动组件：当组件的更新完全由输入属性变化触发，不需要响应其他异步事件（如定时器、HTTP请求回调）时，这种写法能避免Angular默认全域变更检测带来的冗余开销。比如高频更新的数据展示组件、复杂可视化组件，可减少不必要的变更检测循环。
• 需要精准控制DOM更新时机的场景：代码里用requestAnimationFrame在detectChanges后执行rendered()，说明需要在浏览器完成重绘、DOM真正更新后执行操作（比如测量元素尺寸、初始化第三方DOM依赖库）。同时通过seed++强制子组件重新渲染，实现父子组件更新时机的解耦。

为什么detach后手动触发变更检测不是无效优化 #

Angular默认的变更检测机制是自上而下的全域遍历：只要父组件或任意上层组件触发变更检测，当前组件哪怕输入没变化，也会被检查一遍。这段代码的逻辑刚好规避了这个问题：

1. 只在必要时触发检测：ngOnChanges仅当组件输入属性真正发生变化时才会被调用，此时手动执行detectChanges()，刚好是组件需要更新的时机，不会做无用功。
2. 避免冗余检测：detach()把组件从Angular的变更检测树中移除后，父组件或其他上层组件触发变更检测时，当前组件不会被遍历到，大幅减少了不必要的检测操作，尤其适合父组件频繁更新但当前组件输入不常变化的场景。
3. 精准控制子组件更新：seed++是在detectChanges()之后执行的，此时当前组件的变更检测已经完成（因为cdr已detach，seed的变化不会触发当前组件的再次检测），但子组件会因为输入属性seed的变化触发自身的变更检测——相当于把当前组件的更新和子组件的更新做了拆分，按需触发子组件渲染。

另外，这种写法也能避免Angular变更检测的“脏检查”循环问题，比如如果rendered()里有修改组件属性的操作，不会触发额外的变更检测，因为组件已经脱离了检测树。

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