Angular中如何通过APP_INITIALIZER与InjectionToken正确延迟提供运行时环境配置

看起来你遇到的是Angular依赖注入和初始化顺序的典型问题——虽然用了APP_INITIALIZER加载配置，但ENVIRONMENT令牌的工厂函数可能在配置加载完成前就被触发，导致抛出"Runtime config not loaded yet!"的错误。我来帮你梳理问题根源和解决方案：

问题根源 #

Angular的模块初始化和依赖注入顺序是这样的：

1. 先加载所有导入的模块，处理它们的提供者
2. 执行所有APP_INITIALIZER定义的初始化函数（等待它们的Promise完成）
3. 最终创建根组件并启动应用

但这里有两个关键点导致你的问题：

• 你的CoreModule.forRoot也注册了ENVIRONMENT的useValue提供者，可能和AppModule里的工厂提供者产生冲突（Angular会以最后注册的为准，但如果某些服务提前注入了CoreModule提供的默认值，会导致逻辑异常）
• 如果某个依赖ENVIRONMENT的服务在模块初始化阶段就被实例化（比如在CoreModule的提供者中，且被其他服务依赖），它会在APP_INITIALIZER执行前就触发ENVIRONMENT的工厂函数，这时候配置还没加载完成

正确的解决方案 #

我们需要确保ENVIRONMENT令牌只有在运行时配置加载完成后才会返回有效值，同时避免多份ENVIRONMENT提供者的冲突。下面是分步修改方案：

1. 清理冲突的ENVIRONMENT提供者 #

首先移除CoreModule中forRoot方法里的ENVIRONMENT注册，因为我们要统一通过运行时配置提供这个令牌，不再需要默认值：

// core.module.ts
export class CoreModule {
  static forRoot(): ModuleWithProviders<CoreModule> {
    return {
      ngModule: CoreModule,
      providers: [
        // 移除这里的ENVIRONMENT提供者
      ],
    };
  }
}

同时修改AppModule中的导入：

// app.module.ts
imports: [
  CoreModule.forRoot(), // 不再传默认environment
],

2. 增强RuntimeConfigService的幂等性 #

修改RuntimeConfigService，确保loadConfig只会被调用一次，避免重复请求：

// runtime-config.service.ts
export class RuntimeConfigService {
  private _config: Environment | null = null;
  private _loadPromise: Promise<void> | null = null; // 新增：缓存加载Promise

  constructor(private http: HttpClient) {}

  loadConfig(): Promise<void> {
    // 如果已经在加载或加载完成，直接返回缓存的Promise
    if (this._loadPromise) return this._loadPromise;

    this._loadPromise = firstValueFrom(this.http.get<Environment>('/config/config.json'))
      .then(config => {
        this._config = config;
      })
      .catch(() => {
        console.warn('Could not load runtime config, using default');
        this._config = {} as Environment;
      });

    return this._loadPromise;
  }

  getConfig(): Environment {
    if (!this._config) {
      throw new Error('Runtime config not loaded yet!');
    }
    return this._config;
  }
}

3. 修改ENVIRONMENT提供者，确保等待配置加载完成 #

调整AppModule中ENVIRONMENT的工厂函数，让它先等待loadConfig完成再返回配置：

// app.module.ts
providers: [
  RuntimeConfigService,
  {
    provide: APP_INITIALIZER,
    multi: true,
    useFactory: (cfg: RuntimeConfigService) => () => cfg.loadConfig(),
    deps: [RuntimeConfigService],
  },
  {
    provide: ENVIRONMENT,
    useFactory: async (cfg: RuntimeConfigService) => {
      // 强制等待配置加载完成后再返回
      await cfg.loadConfig();
      return cfg.getConfig();
    },
    deps: [RuntimeConfigService],
  },
]

这里的关键是：

• 保留APP_INITIALIZER确保配置在应用启动前就开始加载（即使没有服务提前注入ENVIRONMENT）
• ENVIRONMENT的工厂函数通过await强制等待配置加载完成，无论注入时机如何，都能拿到有效值
• RuntimeConfigService的幂等性保证了即使loadConfig被多次调用，也只会发起一次HTTP请求

4. 可选：处理极端场景的默认值 #

如果你担心某些边缘情况（比如loadConfig一直失败），可以修改getConfig方法，返回一个安全的默认值而不是抛出错误：

// runtime-config.service.ts
getConfig(): Environment {
  return this._config || ({} as Environment);
}

这样即使配置加载失败，也不会导致应用崩溃，而是使用空的默认环境对象。

为什么这样能解决问题？ #

• 我们移除了多份ENVIRONMENT提供者的冲突，确保只有一个权威的提供者
• ENVIRONMENT的工厂函数通过await强制等待配置加载完成，无论注入时机如何，都能拿到有效值
• RuntimeConfigService的幂等性保证了即使loadConfig被多次调用，也只会发起一次HTTP请求
• APP_INITIALIZER确保配置在应用启动阶段就开始加载，不会延迟到第一个服务注入ENVIRONMENT时才开始请求

内容来源于stack exchange