在ngAfterViewChecked中调用detectChanges()是否存在问题？

这种写法虽然可以临时压下ExpressionChangedAfterItHasBeenCheckedError类的报错，但本身存在明确的运行隐患，绝非等价于开发模式下的双次变更检测逻辑，具体弊端如下：

• 极易触发无限检测循环，直接造成页面卡死
  ngAfterViewChecked是每一轮变更检测完成视图渲染后触发的生命周期钩子，在这个钩子里调用detectChanges()，会手动启动一轮新的、从当前组件开始的子树变更检测；新的检测跑完后，又会再次遍历触发所有相关组件的ngAfterViewChecked钩子。只要后续代码中存在任何会修改绑定值、触发视图更新的逻辑，就会再次调用detectChanges，最终形成无法中断的检测死循环，抛出栈溢出错误导致页面完全无响应。
• 会造成无意义的性能损耗
  开发模式下Angular默认执行两次变更检测，是框架内置的稳定性校验逻辑：第一次检测完成后复跑一次，确认绑定表达式没有被意外修改，校验完成后就会终止整个检测流程，不会无限叠加。但在ngAfterViewChecked中手动调用detectChanges的逻辑不受框架校验边界控制，无论开发还是生产环境，每完成一轮视图检查就会强制跑一遍完整的子树检测，组件嵌套层级越深、绑定逻辑越复杂，重复计算的开销就越大，最终会引发交互卡顿、页面掉帧的问题。
• 会掩盖架构层面的时序错误，累积技术债
  Angular抛出的"表达式变更后检测"类报错，本质是框架的设计提示：所有视图绑定的可观测值变更，都应该在变更检测周期启动前、或是ngDoCheck这类允许修改值的生命周期内完成，而不是在视图已经渲染完成的After系列钩子里随意修改。靠手动detectChanges压下报错的做法，会让团队忽略时序设计上的缺陷，后续同类问题会被反复复制成这种临时补丁，最终整个应用的检测逻辑完全失控，出现UI更新时无法定位触发源的排查难题。
• 可能引发时序混乱的隐性异常
  手动触发的检测会打乱Angular默认的更新顺序，比如可能出现父组件视图已经完成更新，但相邻兄弟组件、全局依赖的状态还未同步的问题，导致UI出现短暂闪烁、值不一致的bug，甚至在部分场景下反而会触发更难排查的变更检测报错。

内容的提问来源于stack exchange，提问作者V.S