组件初始化时钩子执行顺序为：constructor → ngOnChanges → ngOnInit → ngDoCheck → ngAfterContentInit → ngAfterContentChecked → ngAfterViewInit → ngAfterViewChecked → ngOnDestroy；其中ngOnInit适合发请求，ngOnDestroy必须清理订阅和定时器。
面试官常问“组件初始化时哪些钩子会执行？顺序怎么排？哪些钩子适合发请求、哪些必须清理？”——这直接关系到你能否写出可维护、无内存泄漏的 Angular 组件，漏掉一个关键节点就可能让接口重复调用或定时器失控。
组件生命周期钩子完整执行顺序
第一步：构造函数（constructor）最先执行，此时组件实例刚创建，【输入属性 @Input 还未绑定，DOM 也未生成】，只适合做基础属性初始化，不能访问 this.el 或调用服务方法。
第二步：ngOnChanges → 只要输入属性变化就会触发，首次调用一定在 ngOnInit 之前；注意它只响应对象引用变化，对对象内部属性修改不敏感——比如传入 {name: 'a'}，后续改 name 字段值，ngOnChanges 不会再触发。
第三步：ngOnInit → 组件首次初始化完成，@Input 已就位，DOM 尚未渲染，是发起 HTTP 请求、订阅 Observable、设置表单的黄金时机。
第四步：ngDoCheck → 每次变更检测周期都会执行，无论数据是否真变；滥用会导致性能暴跌，仅用于手动检测不可监听的变化（如纯 JS 对象属性变更）。
第五步：ngAfterContentInit → 父组件投射（ng-content）的内容已初始化完毕，可安全操作投影内容中的 ElementRef 或 QueryList。
第六步：ngAfterContentChecked → 投影内容被检查后触发，慎用，容易引发 ExpressionChangedAfterItHasBeenCheckedError。
第七步：ngAfterViewInit → 组件自身模板的视图（含子组件视图）首次渲染完成，此时能安全获取本地 templateRef、ViewChild 元素，适合做 DOM 尺寸测量或第三方库初始化（如 Chart.js）。
第八步：ngAfterViewChecked → 视图检查后触发，同 ngAfterContentChecked，非必要不写逻辑。
第九步：ngOnDestroy → 组件销毁前最后一步，必须在此取消所有订阅、清除定时器、移除事件监听器，否则必然造成内存泄漏。
ngOnChanges 和 ngOnInit 的典型误用场景
方法一：把 HTTP 请求写在 ngOnChanges 里 —— 如果父组件频繁更新 @Input，请求就会反复发起，且首次调用时 this.http 可能还没注入完成，直接报 Cannot read property 'get' of undefined。
方法二：在 ngOnInit 中直接读取未初始化的 @Input 属性 —— 某些异步传入的 Input（如路由参数解析后才赋值）可能仍为 undefined，应加判空或改用 async pipe。
方法三：在 ngOnDestroy 中忘记取消 Subject.subscribe() 返回的 Subscription —— 这会导致 Observable 持续推送数据，即使组件已销毁，回调仍执行，UI 错乱或报错。
OnPush 策略下生命周期钩子的触发条件
当组件设置 changeDetection: ChangeDetectionStrategy.OnPush 后，Angular 不再自动遍历检测其子树。此时：
ngOnChanges 仍会在 @Input 引用变化时触发——这是唯一能主动唤醒 OnPush 组件的钩子。
ngOnInit、ngAfterViewInit 等只在首次渲染时执行一次，后续不会因父组件重绘而重复调用。
【ngDoCheck 在 OnPush 下依然每轮都执行，它是打破 OnPush 静默的唯一可控入口】，但代价是放弃性能优化收益，需严格评估必要性。
信号（Signals）时代下的生命周期替代方案
Angular 16+ 推出 Signals 后，部分传统钩子正被更细粒度的响应式模式取代：
用 effect(() => { ... }) 替代 ngOnInit + ngOnDestroy 组合：自动追踪依赖信号，在信号变化时运行，组件销毁时自动清理。
用 computed(() => user().name) 替代 ngOnChanges 手动比对：响应式推导，无需关注变化来源和时机。
effect 内部若发起 HTTP 请求，必须显式调用 destroy() 或使用 onCleanup 回调，否则 effect 不会随组件卸载而停止。
