Angular中为何在ContentChildren变更回调中使用延迟为0的setTimeout

ExpressionChangedAfterItHasBeenCheckedError的触发和代码逻辑本身无关，完全是Angular同步变更检测机制的约束导致的，具体原因拆解如下：

• Angular的变更检测是单轮同步执行的流程：每次检测启动后，会依次执行所有组件/指令的生命周期钩子、匹配模板绑定值、收集@ContentChildren这类内容查询结果、执行所有同步订阅回调，等所有流程走完后，Angular会做一次快照校验。如果检测过程中发现绑定值被中途修改过，就会直接抛出ExpressionChangedAfterItHasBeenCheckedError。
• contentChildren.changes事件的触发时机，本身就处于当前变更检测周期的执行阶段内部：如果在这个事件的同步回调里直接调用updateContentChildren，本质是在Angular还没走完检测流程、还没做快照校验的中途，直接修改子指令（绑定在<td>上的PaCellColor）的内部状态（调用setColor修改样式类），刚好踩中校验逻辑的红线，触发报错。
• 0延迟的setTimeout的核心作用，是把回调从当前同步检测流程中摘出来：哪怕延迟时间写的是0，这个回调也会被放到浏览器的宏任务队列里，等Angular把当前这一整轮变更检测走完、完成所有校验、界面渲染完成之后，才会执行这个回调。这时候再去修改子指令的状态，属于触发下一轮变更检测的合法操作，完全不会触发校验报错。
• 这种写法本身是作者图省事的实现选择：不需要手动注入ChangeDetectorRef手动控制检测时机，直接利用宏任务的异步特性把状态修改操作挪出当前检测周期，是前端开发中非常通用的规避该类报错的方法。
• 为什么同个updateContentChildren方法在ngOnChanges里直接调用就不会报错？因为ngOnChanges本身就是Angular变更检测流程中预留的、允许修改状态的正规环节，这里的状态修改是框架预期内的操作，不会触发校验拦截。

补充澄清：很多人误以为这个setTimeout是为了等DOM渲染完成才修改样式，实际上哪怕你的修改操作和DOM渲染完全无关，只要在contentChildren.changes的同步回调里修改状态，不加延迟就大概率会触发这个报错。

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