：Injector 与 Provider 的核心逻辑)
Angular 的依赖注入（Dependency Injection，简称 DI）是其核心设计理念之一，它不仅让代码解耦更彻底、测试更便捷，更是 Angular 框架各类服务、指令、组件协作的底层基石。很多开发者在使用 Angular 时，只停留在@Injectable()装饰器和构造函数注入的表层用法，却对背后的注入器（Injector）、提供商（Provider）如何协同工作一知半解。本文将从底层逻辑出发，拆解 Angular DI 的核心机制，带你搞懂 Injector 的层级体系和 Provider 的配置规则。
一、DI 的核心价值：为什么 Angular 离不开依赖注入？
在深入技术细节前，先明确 DI 的核心作用 ——解耦对象的创建与依赖管理。
假设我们有一个UserService用于处理用户数据，一个UserComponent需要使用它：
// 无DI的写法：组件直接创建依赖，耦合度高 class UserService { getUser() { return { id: 1, name: '张三' }; } } @Component({ selector: 'app-user' }) class UserComponent { private userService: UserService; constructor() { this.userService = new UserService(); // 硬编码创建，测试/替换困难 } }这种写法的问题显而易见：组件与服务强耦合，测试时无法 mockUserService；若UserService依赖其他服务（如HttpService），组件还需手动传递依赖，代码复杂度指数级上升。
而 DI 的思路是：对象不自行创建依赖，而是由外部 “注入器” 统一创建并注入。组件只需声明 “我需要什么”，无需关心 “依赖从哪来、怎么创建”—— 这正是 Angular DI 的核心价值。
二、核心概念：Injector、Provider、Token
要理解 Angular DI，首先要掌握三个核心概念：
| 概念 | 核心作用 |
|---|---|
| Token（令牌） | 依赖的 “唯一标识”，Angular 通过 Token 找到对应的依赖实例 |
| Provider（提供商） | 定义 “Token 与实际实现的映射关系”，告诉注入器 “如何创建依赖” |
| Injector（注入器） | DI 的 “执行者”，根据 Token 查找 Provider，创建 / 获取依赖实例并注入到目标对象中 |
1. Token：依赖的唯一标识
Token 是 Angular 查找依赖的 “钥匙”，可以是以下类型：
- 类本身（最常用）：如
UserService作为 Token，指向UserService的实例； - InjectionToken：用于非类依赖（如字符串、数字、接口）；
- OpaqueToken（已废弃，被 InjectionToken 替代）。
示例：用InjectionToken定义常量依赖
// 定义Token export const API_BASE_URL = new InjectionToken<string>('API_BASE_URL'); // 配置Provider providers: [ { provide: API_BASE_URL, useValue: 'https://api.example.com' } ] // 注入使用 constructor(@Inject(API_BASE_URL) private baseUrl: string) {}2. Provider：告诉注入器 “如何创建依赖”
Provider 是一个配置对象，核心是定义 “Token 对应什么”，Angular 支持 5 种 Provider 配置方式：
| 配置方式 | 用途 | 示例 |
|---|---|---|
| useClass | 映射到类，注入器会实例化该类 | { provide: UserService, useClass: UserService } |
| useValue | 映射到固定值（常量、对象、函数），适用于静态依赖 | { provide: API_BASE_URL, useValue: 'https://api.example.com' } |
| useFactory | 映射到工厂函数，通过函数动态创建依赖（支持依赖其他服务） | { provide: UserService, useFactory: (http: HttpClient) => new UserService(http), deps: [HttpClient] } |
| useExisting | 别名（复用已有 Token 的实例），适用于 “一个服务多个标识” | { provide: LegacyUserService, useExisting: UserService } |
| ClassProvider | 简写形式（直接传类），等价于 {provide: UserService, useClass: UserService} | providers: [UserService] |
3. Injector：依赖的 “创建与分发中心”
Injector 是 Angular DI 的核心执行器，其核心能力：
- 接收 Token，查找对应的 Provider；
- 根据 Provider 的配置创建 / 获取实例；
- 将实例注入到目标对象（组件、服务、指令等）中。
（1）Injector 的层级体系
Angular 的 Injector 不是全局单例，而是层级化的，核心层级包括：
- 根注入器（Root Injector）：应用级别的注入器，通过
platformBrowserDynamic().bootstrapModule(AppModule)创建，全局唯一； - 模块注入器（Module Injector）：每个 NgModule 有自己的注入器（Angular 6 + 后，模块注入器与根注入器合并，除非使用
@Injectable({ providedIn: 'any' })）； - 组件注入器（Component Injector）：每个组件实例对应一个注入器，组件销毁时注入器也销毁；
- 指令 / 管道注入器：依附于组件注入器，优先级低于组件但高于模块。
层级查找规则：从当前组件注入器开始，向上遍历父组件、模块、根注入器，直到找到匹配的 Token。若找不到，则抛出NullInjectorError。
示例：层级注入的优先级
// 根注入器配置UserService @NgModule({ providers: [{ provide: UserService, useValue: { name: '根服务' } }] }) export class AppModule {} // 父组件配置UserService @Component({ selector: 'app-parent', providers: [{ provide: UserService, useValue: { name: '父组件服务' } }] }) export class ParentComponent {} // 子组件（无Provider），注入UserService会拿到父组件的实例 @Component({ selector: 'app-child' }) export class ChildComponent { constructor(private userService: UserService) { console.log(this.userService.name); // 输出：父组件服务 } }（2）Injector 的实例缓存规则
为了避免重复创建实例，Injector 遵循 “同一层级，同一 Token，单例” 原则：
- 同一注入器中，首次解析 Token 时创建实例，后续直接返回缓存的实例；
- 不同层级的注入器，即使 Token 相同，也会创建独立实例。
例外：@Injectable({ providedIn: 'root' })的服务，默认在根注入器中单例；若配置providedIn: 'any'，则每个注入器层级都会创建独立实例。
三、Provider 的配置策略：providedIn vs 组件 / 模块 providers
Angular 提供了两种核心的 Provider 配置方式，对应不同的作用域和性能表现：
1. @Injectable ({providedIn: ...})：服务级配置（推荐）
这是 Angular 6 + 推荐的配置方式，直接在服务类上通过providedIn指定作用域：
// 根注入器（全局单例） @Injectable({ providedIn: 'root' }) export class UserService {} // 仅在AppModule中可用 @Injectable({ providedIn: AppModule }) export class UserService {} // 每个注入器层级创建独立实例 @Injectable({ providedIn: 'any' }) export class UserService {} // 懒加载模块专用（模块加载时创建，卸载时销毁） @Injectable({ providedIn: LazyModule }) export class UserService {}优势：
- 树摇优化（Tree Shaking）：若服务未被使用，会被打包工具剔除，减小包体积；
- 自动管理作用域，避免手动在模块 / 组件中配置；
- 减少 “提供商重复配置” 导致的实例冲突。
2. 组件 / 模块的 providers 数组：局部配置
适用于 “局部作用域的依赖”（如组件专属服务）：
// 组件级Provider（组件销毁时服务实例销毁） @Component({ selector: 'app-user', providers: [UserService] }) export class UserComponent {} // 模块级Provider（Angular 6+后等价于根注入器，除非懒加载模块） @NgModule({ providers: [UserService] }) export class AppModule {}注意：懒加载模块的providers会创建独立的模块注入器，服务实例仅在该模块内有效。
四、DI 的执行流程：从注入到实例化
以组件注入UserService为例，完整执行流程：
- 组件实例化时，Angular 解析其构造函数参数，提取
UserService作为 Token； - 从当前组件的注入器开始，向上遍历层级注入器，查找
UserService对应的 Provider； - 找到 Provider 后，根据配置创建实例：
useClass：调用类的构造函数（若有依赖，递归解析依赖）；useValue：直接返回固定值；useFactory：执行工厂函数，传入依赖参数，返回实例；useExisting：查找别名 Token 的实例并返回；
- 将创建的实例缓存到当前注入器，然后注入到组件的构造函数中；
- 组件后续可直接使用注入的实例。
五、常见问题与最佳实践
1. 常见问题
- NullInjectorError：Token 未配置 Provider，或层级查找失败；
- 多个实例冲突：不同层级配置了相同 Token，导致拿到非预期实例；
- 循环依赖：A 服务依赖 B，B 又依赖 A，需通过
Injector手动注入解决：@Injectable({ providedIn: 'root' }) export class AService { private bService: BService; constructor(private injector: Injector) { // 延迟注入，避免循环依赖 setTimeout(() => { this.bService = this.injector.get(BService); }); } }
2. 最佳实践
- 优先使用
providedIn: 'root'：减少手动配置，支持树摇，全局单例更易管理； - 局部服务用组件 providers：组件专属服务配置在组件
providers中，随组件销毁释放资源； - 非类依赖用 InjectionToken：避免原始类型（字符串、数字）作为 Token 导致冲突；
- 懒加载模块用
providedIn: 模块名：避免根注入器污染，减小初始包体积； - 避免全局滥用单例：仅核心服务（如 Auth、Http 拦截器）用根注入器，业务服务按作用域隔离。
六、总结
Angular DI 的核心是 “Injector 层级查找 + Provider 映射规则”：Token 作为依赖标识，Provider 定义依赖的创建方式，Injector 则按层级查找 Provider 并创建 / 缓存实例。理解这一逻辑，不仅能解决日常开发中的 DI 报错，更能设计出解耦、可测试、可扩展的 Angular 应用。
从表层的constructor(private service: Service)到底层的 Injector 层级体系，Angular DI 的设计体现了 “控制反转” 的核心思想 —— 将依赖的管理权从业务代码中剥离，交由框架统一管理。掌握 DI 的底层逻辑，是从 “会用 Angular” 到 “用好 Angular” 的关键一步。
