NG0203: por que o inject() falha fora do contexto de injeção

A janela, e quando ela fecha#

A mensagem completa é inject() must be called from an injection context. O contexto de injeção é a janela de runtime em que o injector atual está ao alcance, e a doc é exata sobre quando ele existe: durante a construção de uma classe que o sistema de DI instancia, nos field initializers dessa classe, numa factory de useFactory ou de InjectionToken, e dentro de qualquer stackframe que roda via runInInjectionContext. Essa é a lista inteira.

A pegadinha é que a janela é estreita. Ela fica aberta enquanto o Angular monta a instância e fecha no instante em que a construção termina. A referência da API diz isso sem rodeio: chamadas ao inject() ficam proibidas depois que a instância já foi criada, em métodos, incluindo os lifecycle hooks. Então a pergunta nunca é *consigo injetar esse tipo*, porque o provider existe. A pergunta é *o contexto de injeção ainda estava aberto quando essa linha rodou*.

Onde o inject() funciona, e onde ele estoura#

A maioria dos NG0203 vem de um número pequeno de lugares de chamada. O padrão se repete: código que roda de forma síncrona enquanto o Angular monta a classe passa, e código adiado pra um callback, um timer, um stream ou o corpo de um método já perdeu a janela.

Leia a tabela pelo lugar de chamada, não pelo tipo. O tipo é injetável em todas as linhas. O que muda é se a linha executa dentro da janela de construção ou depois dela.

As armadilhas que parecem inofensivas#

A primeira armadilha é o inject() dentro de um subscribe. O constructor parece certo, o lugar da chamada parece certo, mas o callback roda quando o valor chega, não quando a classe é montada, e a essa altura o contexto já fechou.

A segunda é o route guard async. Um CanActivateFn roda num contexto de injeção quando começa, então o primeiro inject() passa. Coloque um await antes do próximo e você saiu da janela síncrona: a doc afirma que o inject só dá pra usar de forma síncrona e não pode ser usado depois de nenhum await. A terceira é a silenciosa. Um getter privado ou um método auxiliar que chama inject() se parece com código de field, mas executa no acesso, muito depois da construção.

export class OrdersComponent {
  private readonly orders = inject(OrderService);

  ngOnInit() {
    this.orders.changes$.subscribe(() => {
      // NG0203: o callback roda depois da construção
      const logger = inject(LoggerService);
      logger.track('orders changed');
    });
  }

  // NG0203: o getter roda no acesso, não durante a construção
  get currency() {
    return inject(LOCALE_ID) === 'pt-BR' ? 'BRL' : 'USD';
  }
}

Os fixes, ranqueados#

Comece no topo desta lista e só desça quando o caso te obrigar. A maior parte do NG0203 some no primeiro passo, porque a referência injetada não precisava ser resolvida tarde, e sim o código foi escrito tarde.

Primeiro, mova o inject() pra um field initializer ou capture a referência uma vez na construção e use depois. O field guarda a dependência; o callback usa o field. Segundo, quando você precisa mesmo resolver dentro de código adiado (um token escolhido em runtime, um injector por chamada), capture o Injector na construção e chame runInInjectionContext(injector, () => inject(X)) onde o trabalho roda. Terceiro, pro caso específico de cleanup de RxJS, o takeUntilDestroyed aceita um DestroyRef explícito, então dá pra capturar o inject(DestroyRef) uma vez e passar pro operador fora do contexto.

Eu recusaria o fix reflexo de embrulhar toda chamada tardia em runInInjectionContext. Ele silencia o NG0203, mas em geral significa que o design adiou uma decisão que era da construção. Quando vejo isso em revisão, pergunto o que de fato é dinâmico ali. Se a resposta é *nada*, a referência deveria ser um field, e não uma busca em runtime.

export class OrdersComponent {
  private readonly orders = inject(OrderService);
  // Capture uma vez, dentro da janela de construção:
  private readonly logger = inject(LoggerService);
  private readonly destroyRef = inject(DestroyRef);

  ngOnInit() {
    this.orders.changes$
      .pipe(takeUntilDestroyed(this.destroyRef))
      .subscribe(() => this.logger.track('orders changed'));
  }
}

O runInInjectionContext, e o await que quebra ele#

Quando a busca é mesmo adiada, injete o Injector (ou o EnvironmentInjector) na construção e reabra o contexto onde você precisar. A assinatura é runInInjectionContext(injector, fn): ele roda a fn com aquele injector disponível, então o inject() funciona dentro da closure e devolve o resultado dela.

Tem um detalhe que engana muita gente, e vale dizer em voz alta: o contexto que o runInInjectionContext abre é síncrono. No momento em que você dá um await dentro da closure, você cai fora dele, e um inject() depois do await estoura NG0203 de novo. Então resolva tudo o que precisa antes do primeiro await, e só depois faça o trabalho assíncrono. Essa é a mesma regra que pega os route guards async, e é o motivo mais comum de um fix com runInInjectionContext ainda falhar.

export class ReportExporter {
  private readonly injector = inject(Injector);

  exportLater() {
    setTimeout(() => {
      runInInjectionContext(this.injector, () => {
        // Resolva de forma síncrona, antes de qualquer await:
        const http = inject(HttpClient);
        const url = inject(REPORT_URL);
        http.get(url).subscribe();
      });
    }, 1000);
  }
}