Angular 分层依赖注入（Hierarchical Injectors）实战指南：EnvironmentInjector 与 ElementInjector 的解析规则、解析修饰符与 providers/viewProviders

Angular 的依赖注入系统天然是分层的：服务可以被限定在应用的不同层级上提供与解析，从而精确控制每个依赖的作用域、生命周期与可见范围。本文以 skills/dev-skills/angular-developer/references/hierarchical-injectors.md 为骨架，结合本仓库 packages/core 中 DI 的真实实现，系统讲解两类 Injector 层级（EnvironmentInjector 与 ElementInjector）、两阶段的依赖解析顺序、inject() 解析修饰符，以及 providers 与 viewProviders 在内容投影场景下的关键差异。读完你将能准确判断"某个依赖最终会从哪个注入器拿到、拿不到时会发生什么"，并写出可预测、易维护的组件级服务作用域设计。

一、为什么需要"分层"的依赖注入

Angular 的依赖注入并不只有"全局单例"这一种形态。引入分层后，同一个 token 可以在不同层级上注册不同的 provider，解析时遵循"就近优先"原则，于是：

• 全局服务（如 HttpClient、认证状态）可以只实例化一次，应用各处共享；
• 组件级服务（如表单状态、编辑器的 undo 栈）可以随组件销毁而销毁，彼此隔离；
• 嵌入内容（<ng-content> 投影进来的消费者内容）是否能看到组件内部服务，可以由开发者显式控制。

整套机制围绕两种 Injector 层级展开，理解它们的组织方式，是推断解析结果的前提。

二、两种 Injector 层级

依据原文档，Angular 中存在两套正交的 injector 树：

1. EnvironmentInjector（环境注入器）层级：通过 @Service()、@Injectable({ providedIn: 'root' })，或在 bootstrap 时以 ApplicationConfig.providers 配置。这类注入器提供的是全局单例（树摇友好的服务通常都挂在这里）。
2. ElementInjector（元素注入器）层级：在每个 DOM 元素上隐式创建，通过 @Component() / @Directive() 中的 providers 或 viewProviders 数组配置。

2.1 EnvironmentInjector 层级：面向全局与模块边界

从源码看，EnvironmentInjector 是一个抽象基类（packages/core/src/di/r3_injector.ts），而实际的根环境注入器由 R3Injector 实现：

export abstract class EnvironmentInjector implements Injector { ... }
export class R3Injector extends EnvironmentInjector implements PrimitivesInjector { ... }

R3Injector 持有一组 provider，并负责单例实例的缓存与生命周期（destroy() 会把实例级 destroy hooks 全部执行，见 r3_injector.ts 与 r3_injector.ts）。

在层级中挂载服务的方式：

• @Injectable({ providedIn: 'root' })：把服务静态绑定到根环境注入器，且具备 tree-shaking 能力——只有实际注入它的代码被保留时，该服务才会被打包。
• @Service()（本仓库中 Angular 主分支已提供该装饰器）：默认 autoProvided 为 true，即"自动提供"（packages/core/src/di/service.ts），效果相当于自动注册为可注入服务；若设置 @Service({ autoProvided: false })，则需要开发者显式在 providers 中提供它。
• ApplicationConfig.providers（配合 bootstrapApplication）或 NgModule 的 providers：在 bootstrap 时构成根环境注入器的 provider 集。

从 @Injectable 的声明看，providedIn 允许的取值包括 InjectorType<any>（如某 NgModule）、'root'、'platform'、'any'、'environment' 或 null（null 表示不属于任何注入器，必须显式列进某个 providers），详见 packages/core/src/di/interface/defs.ts。这是判断"某 token 究竟被多少个实例满足"的第一手依据。

在实际应用中，EnvironmentInjector 层级还包括：懒加载路由/组件在加载时为自身创建的独立环境注入器，因此"每次懒加载会得到一套新的环境注入器实例"。

2.2 ElementInjector 层级：面向模板树

每个 DOM 元素都会隐式关联一个元素注入器（NodeInjector），它由组件/指令上的 provider 元数据填充。之所以能做到"每个元素都有注入器"，是因为 Angular 为 provider 使用Bloom filter位掩码做了高效索引——token 会与 __NG_ELEMENT_ID__ 关联，见 packages/core/src/render3/di.ts 的实现注释。也就是说，元素注入器并非真正的"对象实例"，而是一套挂在视图数据（LView/TNode）上的哈希索引加缓存结构，这让"在模板树的每个节点做依赖查找"保持低成本。

import {Component} from '@angular/core';
import {SessionService} from './session.service';

@Component({
  selector: 'app-session-box',
  providers: [SessionService], // 每个 <app-session-box> 元素一份
})
export class SessionBox {}

这里 SessionService 的生命周期与 <app-session-box> 元素绑定：组件销毁时实例随之销毁，互不共享。

三、依赖解析规则：先沿 ElementInjector 树向上，再进 EnvironmentInjector 树

当代码请求一个依赖时，Angular 分两阶段解析（原文档 hierarchical-injectors.md 明确给出了该顺序）：

1. 从发起请求的组件/指令所在元素开始，沿 ElementInjector 树向上（即沿模板嵌套的 DOM 元素一路回溯到根元素）；
2. 若未命中，则从最近的 EnvironmentInjector 开始沿该树向上直到根；
3. 仍然找不到就抛出错误——除非该依赖被标记为 optional。

源码把这条链路实现为 getOrCreateInjectable：先从当前 tNode 出发沿着节点注入器树查找，找不到再落到模块（环境）注入器：

// packages/core/src/render3/di.ts
export function getOrCreateInjectable<T>(...): T | null { ... }

其中对 ElementInjector 树的遍历（配合 bloom filter）集中在 render3/di.ts，而"元素树未命中后回退到环境注入器"的逻辑由 lookupTokenUsingModuleInjector 完成（render3/di.ts）。值得注意的是：当标志位带有 Self 或 Host 时，查找不会继续上升进环境注入器（对应 lookupTokenUsingModuleInjector 中 (flags & (Self | Host)) === 0 的判据）。

树的最顶端是一个 NullInjector：当一切查找都失败且未标记 optional 时，它会抛出运行期错误：

// packages/core/src/di/null_injector.ts
export class NullInjector implements Injector {
  get(token: any, notFoundValue: any = THROW_IF_NOT_FOUND): any {
    if (notFoundValue === THROW_IF_NOT_FOUND) {
      const message = ngDevMode ? `No provider found for \`${stringify(token)}\`.` : '';
      // RuntimeErrorCode.PROVIDER_NOT_FOUND
      ...
    }
    return notFoundValue;
  }
}

因此浏览器控制台常见的 NullInjectorError: No provider found for X 正是这一阶段的产物（见 null_injector.ts）。它同时也是排查"服务忘记注册/注册层级不对"的最直接线索。

一个典型的综合结论示例：

<app-root>                              <- ElementInjector(根元素)
  └─ <app-user-profile>                 <- ElementInjector: providers: [ProfileStore]
       └─ <profile-header>              <- ElementInjector: 注入 ProfileStore

<profile-header> 内部请求 ProfileStore 时，先沿元素树向上命中 <app-user-profile> 元素注入器，完成解析；该实例与 <app-user-profile> 同生共死。若中间某层又提供了同名 token，则更内层的组件会拿到"离自己最近的那一份"——这正是分层注入实现"局部覆盖全局"的根基。

四、解析修饰符（Resolution Modifiers）：精确控制查找范围

Angular 允许用 inject() 的 options 对象来修改默认查找行为。原文档给出了四个修饰符，本仓库对应的公共 API 声明位于 packages/core/src/di/interface/injector.ts：

export interface InjectOptions {
  optional?: boolean;   // 找不到时返回 null，而不是抛错
  skipSelf?: boolean;   // 从父级注入器开始查找，跳过当前注入器
  self?: boolean;       // 只查当前注入器，不向父级回溯
  host?: boolean;       // 查找止步于宿主组件的视图边界
}

在运行时，这些布尔选项会被翻译成 InternalInjectFlags 位掩码（packages/core/src/di/interface/injector.ts）：

语义	options	等价装饰器（构造器参数注入时）	内部位标志	说明
默认	缺省	无	Default = 0b0000	检查自身及其父链，直至环境注入器
仅当前注入器	{ self: true }	@Self()	0b0010	找不到就失败，不向父级与环境注入器上升
跳过当前注入器	{ skipSelf: true }	@SkipSelf()	0b0100	直接从父元素注入器开始找
找不到返回 null	{ optional: true }	@Optional()	0b1000	命中失败时返回 null 而非抛错
止步宿主边界	{ host: true }	@Host()	0b0001	用于元素注入器，遇到宿主组件视图边界即停

原文档中的代码示例可直接使用：

import {Component, inject} from '@angular/core';
import {MyService, ParentService} from './services';

@Component({
  selector: 'app-example',
  providers: [MyService],
})
export class Example {
  // 找不到 MyService 时返回 null，而不是抛 NullInjectorError
  optionalService = inject(MyService, {optional: true});

  // 跳过当前组件自己的 providers，从父级注入器查找 ParentService
  // （可用于"在子级重新提供一份默认值、但依然能读取父级实现"的场景）
  parentService = inject(ParentService, {skipSelf: true});
}

4.1 传统构造器参数注入的等价写法

如果你的代码风格仍使用构造器注入，Angular 提供了功能完全一致的参数装饰器。它们与函数式 inject() 的差异仅是语法位置不同：inject() 只允许在注入上下文（构造器、字段初始化、provider 工厂等，参考 injection-context.md）内调用。

import {Component, Optional, Self, SkipSelf} from '@angular/core';
import {Logger} from './logger';

@Component({
  selector: 'app-log',
  providers: [Logger],
})
export class LogComponent {
  // 只认自己元素上的 Logger，找不到就报错
  constructor(@Self() private logger: Logger) {}

  // 跳过本组件提供的 Logger，去父级找；找不到则取 null
  // 常见于：本组件自己的 providers 里也注册了默认实现
  constructor2 = inject(Logger, {skipSelf: true, optional: true});
}

4.2 修饰符的组合与反模式

• {skipSelf: true, optional: true} 是官方推荐的高频组合：用于"本层必须提供一份默认实现，但默认实现又需要读取父层已有实现"的包装场景（例如给默认配置服务做 fallback）。
• 谨慎使用 self：它会切断向环境注入器（全局 provider）回溯的通道，很容易导致"明明在 root 里提供了却仍报 No provider"。
• optional 不等于"吞掉错误"：如果找到 provider 但构造过程抛错，该异常不会因 optional 而静默。

五、providers 与 viewProviders：投影内容（<ng-content>）的可见性边界

在组件级提供服务时，providers 和 viewProviders 的关键区别在于对投影内容是否可见。原文档给出了精炼定义：

• providers：服务对组件、组件的视图（模板）以及**任何投影进来的内容（<ng-content> 中的消费者内容）**都可见；
• viewProviders：服务只对组件及其视图可见，投影内容不可见。

为什么需要 viewProviders？它的价值在于隔离：当你的组件是一个"带插槽的容器"，且不希望消费者透过 ng-content 意外拿到你内部实现细节（或与你内部实例发生耦合）时，就应把内部服务放进 viewProviders。典型如各种数据表格、卡片、插槽型弹层组件。

import {Component} from '@angular/core';
import {CardService} from './card.service';

@Component({
  selector: 'app-card',
  // 该组件内部的子视图（模板中声明的元素）能注入 CardService
  viewProviders: [CardService],
  template: `
    <section class="card">
      <!-- 模板内自己的子组件：能看到 CardService -->
      <app-card-header/>
      <!-- 被投影进来的消费者内容：看不到 CardService！ -->
      <ng-content/>
    </section>
  `,
})
export class Card {}

@Component({
  selector: 'app-consumer',
  providers: [CardService], // 消费者自己提供一份
  template: `
    <app-card>
      <app-card-actions/> <!-- 若未自行提供，这里的 CardService 解析将失败 -->
    </app-card>
  `,
})
export class Consumer {}

判断技巧：凡是写在当前组件模板（含其指令、内容子组件）里的解析需求，providers 和 viewProviders 都能满足；凡是来自 <ng-content> 投影的"外部世界"代码，只有 providers 能满足。所以在设计可复用容器组件时，对外只通过 providers 暴露必要的公共服务契约，把内部协作服务一律放到 viewProviders，就可以获得干净的封装边界。

六、在独立组件（standalone）与懒加载路由中的应用

自 Angular 引入 standalone 组件与 bootstrapApplication(..., {providers}) 后，EnvironmentInjector 层级仍保持不变：

// main.ts（示意）
import {bootstrapApplication} from '@angular/platform-browser';
import {appConfig} from './app.config';
import {AppComponent} from './app/app.component';

bootstrapApplication(AppComponent, appConfig);

// app.config.ts（示意）
export const appConfig: ApplicationConfig = {
  providers: [
    // 根环境注入器：全局单例，全应用可见
    provideHttpClient(),
    {provide: GLOBAL_CONFIG, useValue: {...}},
  ],
};

若在根 providers 与某个组件 providers 中同时提供同一 token，那么该组件树内解析时优先命中最近的 ElementInjector 实例，根环境注入器中的全局单例被"遮蔽"——这正是构建"可测试的局部覆盖/可替换模块"的底层能力。

当组件既有跨组件共享需求又希望懒加载时，可让独立组件自身带上 providers，让 Angular 在路由懒加载时为每条懒加载路由创建独立的环境注入器，从而做到"功能模块级单例、随路由按需加载与销毁"。

七、综合：如何判断一个服务实例的归属

拿到任何一个注入点，按下面顺序做静态推演即可确定实例归属：

1. 该 token 在组件/指令的 viewProviders 中提供 → 仅组件自身视图可见，投影内容不可见；
2. 在组件/指令的 providers 中提供 → 元素注入器命中，实例与元素共存亡；投影内容可见；
3. 在模块/ApplicationConfig.providers / providedIn: 'root' 中提供 → 环境注入器命中，多为全局单例；
4. 都没有 → 触发 null_injector.ts 的 No provider found 运行期错误（除非带了 optional）。

涉及源码深入，可对照两条核心实现链：负责"元素树→环境树"两级回溯的 render3/di.ts，以及负责环境注入器注册与销毁的 r3_injector.ts。其中 Bloom filter 的按位命中意味着：一次请求在元素树上的遍历通常是 O(1) 级别的位运算判断，因此不必为分层机制担忧运行开销。

延伸阅读

• 本文对应技能参考： references/hierarchical-injectors.md
• DI 概念总览与提供方写法： references/di-fundamentals.md、references/defining-providers.md
• 服务创建与作用域选择： references/creating-services.md
• inject() 的使用边界： references/injection-context.md
• 源码级佐证：EnvironmentInjector/R3Injector（packages/core/src/di/r3_injector.ts）、InjectOptions 与内部标志位（packages/core/src/di/interface/injector.ts）、两级查找实现（packages/core/src/render3/di.ts）、兜底错误抛出（packages/core/src/di/null_injector.ts）