effect 内部能否访问注入器？若能，如何确保其生命周期与依赖注入上下文一致？

effect 为何能访问注入器

effect() 在调用时并不自动为回调提供注入上下文，但 Angular 允许在 effect 创建时捕获调用处的注入环境。如果是在组件构造函数或字段初始化这类同步并且处于注入上下文的位置调用 effect，Angular 会把该上下文与 effect 记录关联，回调后续执行时，即使不在组件代码路径中，也能调用 inject() 获取相同注入器下的依赖。

生命周期上，effect 由创建它的注入环境管理。例如组件销毁时，Angular 会自动停止其中创建的 effect 并释放内部订阅，这保证了 effect 不会在组件销毁后继续运行。因此，只要在正确的注入上下文中创建，effect 的生命周期就与依赖注入上下文完全一致，无需额外代码同步销毁。

在组件中正确使用 effect 获取服务

一个用户卡片组件需要显示来自 UserPrefs 的欢迎语。组件构造函数中调用 effect，并在回调里调用 inject(UserPrefs) 来获取服务实例。effect 在构造函数中创建时捕获了组件注入器，因此回调执行时调用 inject() 能够成功。effect 随组件实例创建而启动，组件销毁时自动终止，不会造成跨组件实例的泄漏。

若将该效果移动到 setTimeout 或其他异步方法中创建，该执行点没有注入上下文，effect() 调用本身会抛出 NG0203 错误。唯一的补救方式是用 runInInjectionContext 并传入预先获取的注入器，但这会失去自动销毁能力，需要手动调用 effect.destroy()。因此，工程上始终推荐在组件或指令的初始化上下文创建 effect。

失败条件与处理代价

最容易失败的场景是从路由事件或 Observable 订阅回调中创建 effect，这些回调本身没有注入上下文。此时调用 effect() 本身就会抛出 NG0203 错误，因此不会创建出可用的 effect，自然也无法绑定到任何组件生命周期。

规避手段是在组件构造函数或字段初始化器中创建 effect，然后把需要注入的服务保存为局部变量供回调闭包使用，不必每次调用 inject()。如果确实需要从异步地方创建 effect，则必须自行持有注入器，并通过 runInInjectionContext 手动管理，但代价是必须显式调用 destroy 方法，一旦遗漏就会造成内存泄漏。因此官方推荐始终从组件或指令的初始化路径创建 effect。

容易答错的地方

认为 effect 回调中调用 inject() 总是可行

实际只有 effect 在注入上下文中创建才允许。Angular 在 effect 创建时检查注入环境，并不在回调运行时检查。若在 setTimeout 等非注入上下文中调用 effect()，会直接抛出 NG0203 错误，根本不会创建 effect，也就没有后续回调。

认为所有 effect 都需要手动销毁

有些开发者误以为 effect 必须手动调用 destroy() 才能防止内存泄漏。实际上，只要在组件或指令等注入上下文中创建，Angular 会自动在对应环境销毁时清理 effect。手动调用 destroy() 不会引发异常，但属于多余操作，最佳实践是让框架接管生命周期。

面试官还会怎么问？

把知识连起来