自定义InjectionToken依赖注入在AOT模式下失效问题排查

你遇到的这个问题很典型——JIT模式下运行正常，但AOT编译时出现依赖解析错误，核心原因是AOT需要静态可分析的依赖元数据，而JIT是运行时解析，对元数据的宽松度更高。我们一步步来排查：

1. 修正装饰器顺序（最可能的原因） #

你的构造函数中，@Inject()和@Optional()的顺序写反了。Angular的装饰器解析有明确顺序要求，@Optional()必须放在@Inject()之前，否则AOT编译器无法正确识别这个参数是可选的。

错误写法：

@Inject(MockEndpoints.TOKEN) @Optional() private endpoints: MockEndpoints[]

正确写法：

@Optional() @Inject(MockEndpoints.TOKEN) private endpoints?: MockEndpoints[]

这里额外给参数加上?标记为可选类型，能让AOT更清晰地识别参数的可选性，避免静态解析时的歧义。

2. 验证服务与接口的兼容性 #

虽然你定义的MockEndpoints.TOKEN是InjectionToken<MockEndpoints[]>，但要确保注册的服务（MockBackupService、MockConfigurationService）确实完整实现了MockEndpoints接口。TypeScript的接口是编译时检查，AOT编译时如果类没有正确实现接口方法（比如handle方法的签名不匹配），会导致DI系统无法将这些类关联到Token上。

可以手动添加编译时验证：

// 编译时检查是否符合接口类型，报错则说明服务实现有问题
const backupService: MockEndpoints = new MockBackupService();
const configService: MockEndpoints = new MockConfigurationService();

3. 排查模块注册细节 #

你已经在MockBackendModule中注册了多提供者，但要注意两个点：

• 确保MockBackendModule被正确导入到应用的根模块（或你需要使用拦截器的功能模块）中，没有重复注册导致的冲突。
• 确认multi: true在两个MockEndpoints.TOKEN的提供者中都正确设置——如果其中一个漏写，会导致之前的提供者被覆盖而非追加，间接引发AOT解析问题。

4. 检查是否存在循环依赖 #

如果MockBackupService或MockConfigurationService中依赖了MockBackendInterceptor，就会形成循环依赖。JIT模式下可能侥幸运行，但AOT编译会严格检查这种情况，导致依赖解析失败。

你可以检查这两个服务的构造函数，看是否注入了MockBackendInterceptor或者依赖了其他间接引用它的服务。如果存在循环依赖，需要重构代码（比如使用Injector延迟获取依赖，或调整服务职责划分）。

5. 为Token添加默认值（兜底方案） #

如果上述方法都无效，可以尝试给InjectionToken提供一个默认值，让AOT编译器明确知道没有提供者时的 fallback 行为：

export namespace MockEndpoints {
  export const TOKEN: InjectionToken<MockEndpoints[]> = new InjectionToken<MockEndpoints[]>('MockEndpoints', {
    providedIn: 'root',
    factory: () => [] // 默认返回空数组
  });
}

这样即使没有注册任何MockEndpoints服务，DI系统也能解析到一个空数组，避免AOT报错。

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