Angular 依赖注入

依赖注入（DI）是用来创建对象及其依赖的其它对象的一种方式。当依赖注入系统创建某个对象实例时，会负责提供该对象所依赖的对象（称为该对象的依赖）。

依赖注入模式中讲解了这种通用的方法。 这里解释的是 Angular 依赖注入系统本身的工作原理。

DI 的例子

在这篇指南中，你将会通过对一个范例应用的讨论来学习 Angular 的依赖注入技术。

先从《英雄指南》中英雄特性区的一个简化版本开始。

src/app/heroes/heroes.component.ts

src/app/heroes/hero-list.component.ts

src/app/heroes/hero.ts

src/app/heroes/mock-heroes.ts

content_copyimport { Component } from '@angular/core';
@Component{
  selector: 'app-heroes',
  template: `
    <h2>Heroes</h2>
    <app-hero-list></app-hero-list>
  `
})
export class HeroesComponent { }

HeroesComponent 是位于顶级的组件。它唯一的用途是显示 HeroListComponent，它显示一个英雄名字的列表。

这个版本的 HeroListComponent 从 HEROES 数组（定义在 mock-heroes 文件中的内存数组）中获取 heroes。

src/app/heroes/hero-list.component.ts (class)

content_copyexport class HeroListComponent {
  heroes = HEROES;
}

在开发的早期阶段，这就够用了，不过还很不理想。当要测试这个组件或者要从远端服务器获取英雄数据时，你就不得不去修改 HeroesListComponent 的实现，并要替换所有使用了 HEROES 模拟数据的地方。

最好隐藏服务类的这些内部实现细节，那就先把它定义在自己的文件中。

创建一个可注入的 HeroService

Angular CLI 可以使用下列命令在 src/app/heroes 目录下新建一个 HeroService 类。

content_copyng generate service heroes/hero

上述命令会创建如下的 HeroService 骨架代码：

src/app/heroes/hero.service.ts (CLI-generated)

content_copyimport { Injectable } from '@angular/core';

@Injectable{
  providedIn: 'root',
})
export class HeroService {
  constructor() { }
}

@Injectable 装饰器是定义每个 Angular 服务时的必备部分。把该类的其它部分改写为暴露一个返回和以前一样的 mock 数据的 getHeroes 方法。

src/app/heroes/hero.service.3.ts

content_copyimport { Injectable } from '@angular/core';import { HEROES }     from './mock-heroes'; @Injectable{  // we declare that this service should be created  // by the root application injector.   providedIn: 'root',})export class HeroService {  getHeroes() { return HEROES; }}

当然，这还不是真正的数据服务。如果该应用真的从远端服务器获取数据，那么 getHeroes 的方法签名就应该是异步形式的。

我们可以放心地忽略这个问题，因为这里的焦点在于把服务注入到 HeroListComponent 组件中。

注入器

在你把 Angular 中的服务类（比如 HeroService ）注册进依赖注入器（injector）之前，它只是个普通类而已。

Angular 的依赖注入器负责创建服务的实例，并把它们注入到像 HeroListComponent 这样的类中。

你很少需要自己创建 Angular 的依赖注入器。当 Angular 运行本应用时，它会为你创建这些注入器，首先会在引导过程中创建一个根注入器。

Angular 本身没法自动判断你是打算自行创建服务类的实例，还是等注入器来创建它。你必须通过为每个服务指定服务提供商来配置它。

提供商会告诉注入器如何创建该服务。如果没有提供商，注入器既不知道它该负责创建该服务，也不知道如何创建该服务。

你可以在稍后的部分学到更多关于提供商的知识。不过目前，你只要知道它们是用来配置服务应该在哪里创建以及如何创建的就够了。

有很多方式可以为注入器注册服务提供商。本节会展示为你的服务配置提供商最常见的途径。

@Injectable 的 providers 数组

@Injectable 装饰器会指出这些服务或其它类是用来注入的。它还能用于为这些服务提供配置项。

这里我们使用类上的 @Injectable 装饰器来为 HeroService 配置了一个提供商。

src/app/heroes/heroes.service.ts

content_copyimport { Injectable } from '@angular/core';

@Injectable{
  providedIn: 'root',
})
export class HeroService {
  constructor() { }
}

providedIn 告诉 Angular，它的根注入器要负责调用 HeroService 类的构造函数来创建一个实例，并让它在整个应用中都是可用的。在使用 CLI 生成新服务时，会默认帮你设置为这种提供商。

有时，你不希望只在应用的根注入器中提供服务。有可能用户希望显式选择要使用的服务，或者应该在一个惰性加载的环境下提供该服务。这种情况下，服务提供商应该关联到一个特定的 @NgModule 类，而且应该用于该模块包含的任何一个注入器中。

下面这段代码中，@Injectable 装饰器用来配置一个服务提供商，它可以用在任何包含了 HeroModule 的注入器中。

src/app/heroes/hero.service.ts

content_copyimport { Injectable } from '@angular/core';
import { HeroModule } from './hero.module';
import { HEROES }     from './mock-heroes';

@Injectable{
  // we declare that this service should be created
  // by any injector that includes HeroModule.

  providedIn: HeroModule,
})
export class HeroService {
  getHeroes() { return HEROES; }
}

@NgModule 中的 providers

在下面的代码片段中，根模块 AppModule 在自己的 providers 数组中注册了两个提供商。

src/app/app.module.ts (providers)

content_copyproviders: [
  UserService,
  { provide: APP_CONFIG, useValue: HERO_DI_CONFIG }
],

第一条使用 UserService 这个注入令牌（injection token）注册了 UserService 类（代码中未显示）。第二条使用 APP_CONFIG 这个注入令牌注册了一个值（HERO_DI_CONFIG）。

借助这些注册语句，Angular 现在可以向它创建的任何类中注册 UserService 或 HERO_DI_CONFIG 值了。

稍后你就会学到关于注入令牌和服务提供商语法的知识。

在组件中注册提供商

除了提供给全应用级或特定的 @NgModule 中之外，服务还可以提供给指定的组件。在组件级提供的服务职能在该组件及其子组件的注入器中使用。

下面的例子展示了一个修改过的 HeroesComponent，它在自己的 providers 数组中注册了 HeroService。

src/app/heroes/heroes.component.ts

content_copyimport { Component } from '@angular/core';
import { HeroService } from './hero.service';

@Component{
  selector: 'app-heroes',
  providers: [ HeroService ],
  template: `
    <h2>Heroes</h2>
    <app-hero-list></app-hero-list>
  `
})
export class HeroesComponent { }

@Injectable、@NgModule 还是 @Component ？

你该使用 @Injectable 装饰器、@NgModule还是 @Component 来提供服务呢？这几个选择的差别在于最终的打包体积、服务的范围和服务的生命周期。

当你在服务本身的 @Injectable 装饰器中注册提供商时，优化工具（比如 CLI 产品模式构建时所用的）可以执行摇树优化，这会移除所有没在应用中使用过的服务。摇树优化会导致更小的打包体积。

Angular 模块中的 providers（@NgModule.providers）是注册在应用的根注入器下的。因此，Angular 可以往它所创建的任何类中注入相应的服务。一旦创建，服务的实例就会存在于该应用的全部生存期中，Angular 会把这一个服务实例注入到需求它的每个类中。

你可能想要把这个 UserService 注入到应用中的很多地方，并期望每次注入的都是同一个服务实例。这时候如果不能用 @Injectable，那么就可以在 Angular 的模块中提供 UserService。

严格来说，Angular 模块中的服务提供商会注册到根注入器上，但是，惰性加载的模块是例外。在这个例子中，所有模块都是在应用启动时立即加载的，因此模块上的所有服务提供商都注册到了应用的根注入器上。

组件的提供商（@Component.providers）会注册到每个组件实例自己的注入器上。

因此 Angular 只能在该组件及其各级子组件的实例上注入这个服务实例，而不能在其它地方注入这个服务实例。

注意，由组件提供的服务，也同样具有有限的生命周期。组件的每个实例都会有它自己的服务实例，并且，当组件实例被销毁的时候，服务的实例也同样会被销毁。

在这个范例应用中，HeroComponent 会在应用启动时创建，并且它从未销毁，因此，由 HeroComponent 创建的 HeroService 也同样会活在应用的整个生命周期中。

如果你要把 HeroService 的访问权限定在 HeroesComponent 及其嵌套的 HeroListComponent 中，那么在 HeroesComponent 中提供这个 HeroService 就是一个好选择。

由组件提供的服务，其范围和生命周期是 Angular 如何创建组件实例的必然结果。

服务提供商们

服务提供商提供依赖值的一个具体的、运行时的版本。注入器依靠提供商来创建服务的实例，注入器再将服务的实例注入组件、管道或其它服务。

必须为注入器注册一个服务的提供商，否则它就不知道该如何创建该服务。

在下面的几节中会解释指定提供商的多种方式。

把类作为它自己的提供商

有很多方式可以提供一些实现 Logger 类的东西。 Logger 类本身是一个显而易见而且自然而然的提供商。

content_copyproviders: [Logger]

但它不是唯一的途径。

可以用其它备选提供商来配置注入器，只要它们能交付一个行为类似于 Logger 的对象就可以了。可以提供一个替代类。你可以提供一个类似日志的对象。可以给它一个提供商，让它调用可以创建日志服务的工厂函数。所有这些方法，只要用在正确的场合，都可能是一个好的选择。

重点是，当注入器需要一个 Logger 时，它得先有一个提供商。

provide 对象字面量

下面是类提供商的另一种语法。

content_copyproviders: [Logger]

这其实是用于注册提供商的简写表达式。使用的是一个带有两个属性的提供商对象字面量：

content_copy[{ provide: Logger, useClass: Logger }]

provide 属性保存的是令牌 (token)，它作为键值 (key) 使用，用于定位依赖值和注册提供商。

第二个是一个提供商定义对象。可以把它看做是指导如何创建依赖值的配方。有很多方式创建依赖值…… 也有很多方式可以写配方。

备选的类提供商

某些时候，你会请求一个不同的类来提供服务。下列代码告诉注入器，当有人请求 Logger 时，返回 BetterLogger。

content_copy[{ provide: Logger, useClass: BetterLogger }]

带依赖的类提供商

假设 EvenBetterLogger 可以在日志消息中显示用户名。这个日志服务从注入的 UserService 中取得用户， UserService 通常也会在应用级注入。

content_copy@Injectable()
export class EvenBetterLogger extends Logger {
  constructor(private userService: UserService) { super( }

  log(message: string) {
    let name = this.userService.user.name;
    super.log(`Message to ${name}: ${message}`
  }
}

就像之前在 BetterLogger 中那样配置它。

content_copy[ UserService,
  { provide: Logger, useClass: EvenBetterLogger }]

别名类提供商

假设某个旧组件依赖一个 OldLogger 类。 OldLogger 和 NewLogger 具有相同的接口，但是由于某些原因，你不能升级这个旧组件并使用它。

当旧组件想使用 OldLogger 记录消息时，你希望改用 NewLogger 的单例对象来记录。

不管组件请求的是新的还是旧的日志服务，依赖注入器注入的都应该是同一个单例对象。也就是说，OldLogger 应该是 NewLogger 的别名。

你当然不会希望应用中有两个不同的 NewLogger 实例。不幸的是，如果尝试通过 useClass 来把 OldLogger 作为 NewLogger 的别名，就会导致这样的后果。

content_copy[ NewLogger,
  // Not aliased! Creates two instances of `NewLogger`
  { provide: OldLogger, useClass: NewLogger}]

解决方案：使用 useExisting 选项指定别名。

content_copy[ NewLogger,
  // Alias OldLogger w/ reference to NewLogger
  { provide: OldLogger, useExisting: NewLogger}]

值提供商

有时，提供一个预先做好的对象会比请求注入器从类中创建它更容易。

content_copy// An object in the shape of the logger service
export function SilentLoggerFn() {}

const silentLogger = {
  logs: ['Silent logger says "Shhhhh!". Provided via "useValue"'],
  log: SilentLoggerFn
};

于是可以通过 useValue 选项来注册提供商，它会让这个对象直接扮演 logger 的角色。

content_copy[{ provide: Logger, useValue: silentLogger }]

查看更多 useValue 的例子，见非类依赖和 InjectionToken部分。

工厂提供商

有时，你需要动态创建这个依赖值，因为它所需要的信息直到最后一刻才能确定。也许这个信息会在浏览器的会话中不停地变化。

还假设这个可注入的服务没法通过独立的源访问此信息。

这种情况下，请调用工厂提供商。

下面通过添加新的业务需求来说明这一点： HeroService 必须对普通用户隐藏掉秘密英雄。只有授权用户才能看到秘密英雄。

就像 EvenBetterLogger 那样，HeroService 需要了解此用户的身份。它需要知道，这个用户是否有权看到隐藏英雄。这个授权可能在单一的应用会话中被改变，例如，改用另一个用户的身份登录时。

与 EvenBetterLogger 不同，不能把 UserService 注入到 HeroService中。 HeroService 无权访问用户信息，来决定谁有授权谁没有授权。

让 HeroService 的构造函数带上一个布尔型的标志，来控制是否显示隐藏的英雄。

src/app/heroes/hero.service.ts (excerpt)

content_copyconstructor(
  private logger: Logger,
  private isAuthorized: boolean) { }

getHeroes() {
  let auth = this.isAuthorized ? 'authorized ' : 'unauthorized';
  this.logger.log(`Getting heroes for ${auth} user.`
  return HEROES.filter(hero => this.isAuthorized || !hero.isSecret
}

你可以注入 Logger，但是不能注入逻辑型的 isAuthorized。你不得不通过通过工厂提供商创建这个 HeroService 的新实例。

工厂提供商需要一个工厂方法：

src/app/heroes/hero.service.provider.ts (excerpt)

content_copylet heroServiceFactory = (logger: Logger, userService: UserService) => {
  return new HeroService(logger, userService.user.isAuthorized
};

虽然 HeroService 不能访问 UserService，但是工厂方法可以。

同时把 Logger 和 UserService 注入到工厂提供商中，并且让注入器把它们传给工厂方法：

src/app/heroes/hero.service.provider.ts (excerpt)

content_copyexport let heroServiceProvider =
  { provide: HeroService,
    useFactory: heroServiceFactory,
    deps: [Logger, UserService]
  };

useFactory 字段告诉 Angular：这个提供商是一个工厂方法，它的实现是 heroServiceFactory。

deps 属性是提供商令牌数组。 Logger 和 UserService 类作为它们自身类提供商的令牌。注入器解析这些令牌，把相应的服务注入到工厂函数中相应的参数中去。

注意，你在一个导出的变量中捕获了这个工厂提供商：heroServiceProvider。这个额外的步骤让工厂提供商可被复用。无论哪里需要，都可以使用这个变量注册 HeroService。

在这个例子中，只在 HeroesComponent 中需要它，这里，它代替了元数据 providers 数组中原来的 HeroService 注册。对比一下新的和旧的实现：

src/app/heroes/heroes.component (v3)

src/app/heroes/heroes.component (v2)

content_copyimport { Component }          from '@angular/core';import { heroServiceProvider } from './hero.service.provider'; @Component{  selector: 'app-heroes',  providers: [ heroServiceProvider ],  template: `    <h2>Heroes</h2>    <app-hero-list></app-hero-list>  `})export class HeroesComponent { }

可以被摇树优化的提供商

摇树优化可以在最终打包时移除应用中从未引用过的代码。可摇树优化的提供商可以让 Angular 从结果中移除应用中那些从未使用过的服务。这可以显著减小打包体积。

理想情况下，如果应用没有注入过某个服务，它就不应该被包含在最终结果中。不过，问题在于 Angular 的编译器无法在构建期间识别出该服务是不是必要的。因为总是可以使用 injector.get(Service) 的形式直接注入某个服务，而 Angular 不能从你的代码中识别出所有能够进行这种注入的地方。所以，Angular 别无选择，只能把这个服务包含到注入器中。因此，在模块中提供的服务也就无法进行摇树优化了。

来看一个 Angular 无法对提供商进行摇树优化的例子。

在这个例子中，为了在 Angular 中提供服务，你把它们都包含进了 @NgModule 中：

src/app/tree-shaking/service-and-modules.ts

content_copyimport { Injectable, NgModule } from '@angular/core';

@Injectable()
export class Service {
  doSomething(): void {
  }
}

@NgModule{
  providers: [Service],
})
export class ServiceModule {
}

接着，该模块可以导入到你的应用模块中，以便让该服务在整个应用中可用：

src/app/tree-shaking/app.modules.ts

content_copy@NgModule{
  imports: [
    BrowserModule,
    RouterModule.forRoot([]),
    ServiceModule,
  ],
})
export class AppModule {
}

当运行 ngc 时，它会把 AppModule 编译进一个模块工厂里，该工厂中含有它包含的所有子模块中声明过的所有提供商。在运行期间，该工厂会编程一个用于实例化这些服务的注入器。

在这种方式下，摇树优化无法工作，因为 Angular 无法根据该代码（服务类）是否被其它代码块使用过（比如该服务的提供商就定义在了模块工厂里）来排除它。要让这些服务可以被摇树优化，所有关于如何构建该服务的实例的信息（提供商定义）就应该是该服务类本身的一部分。

创建可摇树优化的服务提供商

要想创建可摇树优化的服务提供商，那些原本要通过模块来指定的信息就要改为在服务自身的 @Injectable 装饰器中提供。

下面的例子展示了一个与上面的 ServiceModule 范例等价的可摇树的优化版本：

src/app/tree-shaking/service.ts

content_copy@Injectable{
  providedIn: 'root',
})
export class Service {
}

上面这个例子中，providedIn 允许你声明要由哪个注入器来注入该服务。除了一些特殊情况外，这个值应该始终是 root（根注入器）。把该值设置为 root 可以确保该服务的范围是根注入器，而不是该注入器所在的那个特定模块。

该服务也可以通过配置一个工厂函数来实例化，例子如下：

src/app/tree-shaking/service.0.ts

content_copy@Injectable{
  providedIn: 'root',
  useFactory: () => new Service('dependency'),
})
export class Service {
  constructor(private dep: string) {
  }
}

要想改写（override）一个可摇树优化的提供商，可以在任何支持 providers: [] 数组的 Angular 装饰器中注册该提供商。

注入某个服务

HeroListComponent 应该从 HeroService 中获取这些英雄数据。

该组件不应该使用 new 来创建 HeroService。它应该要求注入 HeroService。

你可以通过在构造函数中添加一个带有该依赖类型的参数来要求 Angular 把这个依赖注入到组件的构造函数中。下面是 HeroListComponent 的构造函数，它要求注入 HeroService。

src/app/heroes/hero-list.component (constructor signature)

content_copyconstructor(heroService: HeroService)

当然，HeroListComponent 还应该使用注入的这个 HeroService 做点什么。下面输出修改过的组件，改用注入的服务，与前一个版本对比一下。

hero-list.component (with DI)

hero-list.component (without DI)

content_copyimport { Component }   from '@angular/core';import { Hero }        from './hero';import { HeroService } from './hero.service'; @Component{  selector: 'app-hero-list',  template: `    <div *ngFor="let hero of heroes">      {{hero.id}} - {{hero.name}}    </div>  `})export class HeroListComponent {  heroes: Hero[];   constructor(heroService: HeroService) {    this.heroes = heroService.getHeroes(  }}

注意，HeroListComponent 并不知道 HeroService 来自哪里。不过，你知道它来自其父组件 HeroesComponent。如果你决定改为在 AppModule 中提供这个 HeroService，HeroListComponent 不需要做任何改动。 唯一需要关心的问题是，HeroService 是由某个父注入器提供的。

单例服务

服务在每个注入器的范围内是单例的。在任何一个注入器中，最多只会有同一个服务的一个实例。

这里只有一个根注入器，而 UserService 就是在该注入器中注册的。所以，在整个应用中只能有一个 UserService 实例，每个要求注入 UserService 的类都会得到这个服务实例。

不过，Angular DI 是一个多级注入系统，这意味着各级注入器都可以创建它们自己的服务实例。 Angular 总会创建多级注入器。

组件的子注入器

组件注入器是彼此独立的，每一个都会为这些组件提供的服务创建单独的实例。

例如，当 Angular 创建一个带有 @Component.providers 的组件实例时，也会同时为这个实例创建一个新的子注入器。

当 Angular 销毁某个组件实例时，也会同时销毁该组件的注入器，以及该注入器中的服务实例。

由于是多层注入器，因此你仍然可以把全应用级的服务注入到这些组件中。组件的注入器是其父组件注入器的孩子，也是其爷爷注入器的孙子，以此类推，直到该应用的根注入器。 Angular 可以注入这条线上的任何注入器所提供的服务。

比如，Angular 可以把由 HeroComponent 提供的 HeroService 和由 AppModule 提供的 UserService 注入到 HeroService 中。

测试组件

前面强调过，设计一个适合依赖注入的类，可以让这个类更容易测试。要有效的测试应用中的一部分，只需要在构造函数的参数中列出依赖。

例如，新建的 HeroListComponent 实例使用一个模拟 (mock) 服务，以便可以在测试中操纵它：

src/app/test.component.ts

content_copyconst expectedHeroes = [{name: 'A'}, {name: 'B'}]
const mockService = <HeroService> {getHeroes: () => expectedHeroes }

it('should have heroes when HeroListComponent created', () => {
  // Pass the mock to the constructor as the Angular injector would
  const component = new HeroListComponent(mockService
  expect(component.heroes.length).toEqual(expectedHeroes.length
}

要学习更多知识，参见测试一章。

当服务需要别的服务时

这个 HeroService 非常简单。它本身不需要任何依赖。

如果它也有依赖，该怎么办呢？例如，它需要通过日志服务来汇报自己的活动。你同样用构造函数注入模式，来添加一个带有 Logger 参数的构造函数。

下面是修改后的 HeroService，它注入了 Logger，对比前后这两个版本：

src/app/heroes/hero.service (v2)

src/app/heroes/hero.service (v1)

content_copyimport { Injectable } from '@angular/core';import { HEROES }     from './mock-heroes';import { Logger }     from '../logger.service'; @Injectable{  providedIn: 'root',})export class HeroService {   constructor(private logger: Logger) {  }   getHeroes() {    this.logger.log('Getting heroes ...'    return HEROES;  }}

这个构造函数要求注入一个 Logger 类的实例，并把它存到名为 logger 的私有字段中。当请求英雄数据时，getHeroes() 中就会记录一个消息。

被依赖的 Logger 服务

这个范例应用的 Logger 服务非常简单：

src/app/logger.service.ts

content_copyimport { Injectable } from '@angular/core';

@Injectable()
export class Logger {
  logs: string[] = []; // capture logs for testing

  log(message: string) {
    this.logs.push(message
    console.log(message
  }
}

如果该应用没有提供这个 Logger 服务，当 Angular 试图把 Logger 注入到 HeroService 中时，就会抛出一个异常。

content_copyERROR Error: No provider for Logger!

因为 Logger 服务的单例应该随处可用，所以要在根模块 AppModule 中提供它。

src/app/app.module.ts (providers)

content_copyproviders: [
  Logger,
  UserService,
  { provide: APP_CONFIG, useValue: HERO_DI_CONFIG }
],

依赖注入令牌

当向注入器注册提供商时，实际上是把这个提供商和一个 DI 令牌关联起来了。注入器维护一个内部的令牌-提供商映射表，这个映射表会在请求依赖时被引用到。令牌就是这个映射表中的键值。

在前面的所有例子中，依赖值都是一个类实例，并且类的类型作为它自己的查找键值。在下面的代码中，HeroService 类型作为令牌，直接从注入器中获取 HeroService 实例：

src/app/injector.component.ts

content_copyheroService: HeroService;

编写需要基于类的依赖注入的构造函数对你来说是很幸运的。只要定义一个 HeroService 类型的构造函数参数， Angular 就会知道把跟 HeroService 类令牌关联的服务注入进来：

src/app/heroes/hero-list.component.ts

content_copyconstructor(heroService: HeroService)

这是一个特殊的规约，因为大多数依赖值都是以类的形式提供的。

非类依赖

如果依赖值不是一个类呢？有时候想要注入的东西是一个字符串，函数或者对象。

应用程序经常为很多很小的因素定义配置对象（例如应用程序的标题或网络 API 终点的地址）。但是这些配置对象不总是类的实例，它们可能是对象，如下面这个：

src/app/app.config.ts (excerpt)

content_copyexport const HERO_DI_CONFIG: AppConfig = {
  apiEndpoint: 'api.heroes.com',
  title: 'Dependency Injection'
};

如果想让这个配置对象在注入时可用该怎么办？你知道你可以用值提供商来注册一个对象。

但是，这种情况下用什么作令牌呢？你没办法找一个类来当作令牌，因为没有 Config 类。

TypeScript 接口不是一个有效的令牌

HERO_DI_CONFIG 常量有一个接口：AppConfig。不幸的是，不能把 TypeScript 接口用作令牌：

content_copy// FAIL! Can't use interface as provider token
[{ provide: AppConfig, useValue: HERO_DI_CONFIG })]

content_copy// FAIL! Can't inject using the interface as the parameter type
constructor(private config: AppConfig){ }

对于习惯于在强类型的语言中使用依赖注入的开发人员，这会看起来很奇怪，因为在强类型语言中，接口是首选的用于查找依赖的主键。

这不是 Angular 的错。接口只是 TypeScript 设计时 (design-time) 的概念。JavaScript 没有接口。 TypeScript 接口不会出现在生成的 JavaScript 代码中。在运行期，没有接口类型信息可供 Angular 查找。

InjectionToken 值

解决方案是为非类依赖定义和使用InjectionToken作为提供商令牌。定义方式是这样的：

content_copyimport { InjectionToken } from '@angular/core';
export const TOKEN = new InjectionToken('desc'

你可以在创建 InjectionToken 时直接配置一个提供商。该提供商的配置会决定由哪个注入器来提供这个令牌，以及如何创建它的值。这和 @Injectable 的用法很像，不过你没法用 InjectionToken 来定义标准提供商（比如 useClass 或 useFactory），而要指定一个工厂函数，该函数直接返回想要提供的值。

content_copyexport const TOKEN = 
  new InjectionToken('desc', { providedIn: 'root', factory: () => new AppConfig(), })

现在，在 @Inject 装饰器的帮助下，这个配置对象可以注入到任何需要它的构造函数中：

content_copyconstructor(@Inject(TOKEN)

如果工厂函数需要访问其它的 DI 令牌，它可以使用来自 @angular/core中的 inject 函数来申请它的依赖。

content_copyconst TOKEN = 
  new InjectionToken('tree-shakeable token', 
    { providedIn: 'root', factory: () => 
        new AppConfig(inject(Parameter1), inject(Paremeter2)), }

可选依赖

可以把构造函数的参数标记为 null 来告诉 Angular 该依赖是可选的：

content_copyconstructor(@Inject(Token, null)

如果要使用可选依赖，你的代码就必须准备好处理空值。

小结

本章，你学习了 Angular 依赖注入的基础知识。你可以注册很多种类的提供商，知道如何通过添加构造函数的参数来请求一个注入对象（例如一个服务）。

Angular 依赖注入比前面描述的更能干。学习更多高级特性，如对嵌套注入器的支持，见多级依赖注入一章。

附录：直接使用注入器

这里的 InjectorComponent 直接使用了注入器，但开发者很少直接使用它。

src/app/injector.component.ts

content_copy@Component{  selector: 'app-injectors',  template: `  <h2>Other Injections</h2>  <div id="car">{{car.drive()}}</div>  <div id="hero">{{hero.name}}</div>  <div id="rodent">{{rodent}}</div>  `,  providers: [Car, Engine, Tires, heroServiceProvider, Logger]})export class InjectorComponent implements OnInit {  car: Car;   heroService: HeroService;  hero: Hero;   constructor(private injector: Injector) { }   ngOnInit() {    this.car = this.injector.get(Car    this.heroService = this.injector.get(HeroService    this.hero = this.heroService.getHeroes()[0];  }   get rodent() {    let rousDontExist = `R.O.U.S.'s? I don't think they exist!`;    return this.injector.get(ROUS, rousDontExist  }}

Injector 本身是可注入的服务。

在这个例子中，Angular 把组件自身的 Injector 注入到了组件的构造函数中。然后，组件在 ngOnInit() 中向注入的注入器请求它所需的服务。

注意，这些服务本身没有注入到组件，它们是通过调用 injector.get()获得的。

get() 方法如果不能解析所请求的服务，会抛出异常。调用 get() 时，还可以使用第二个参数，一旦获取的服务没有在当前或任何祖先注入器中注册过，就把它作为返回值。

刚描述的这项技术是服务定位器模式的一个范例。

要避免使用此技术，除非确实需要它。它会鼓励鲁莽的方式，就像在这里看到的。它难以解释、理解和测试。仅通过阅读构造函数，没法知道这个类需要什么或者它将做什么。它可以从任何祖先组件中获得服务，而不仅仅是它自己。会迫使你深入它的实现，才可能明白它都做了啥。

框架开发人员必须采用通用的或者动态的方式获取服务时，可能采用这个方法。

附录：为什么建议每个文件只放一个类

在同一个文件中有多个类容易造成混淆，最好避免。开发人员期望每个文件只放一个类。这会让他们开心点。

如果你要把 HeroService 和 HeroesComponent 组合在同一个文件里， 就得把组件定义放在最后面！ 如果把组件定义在了服务的前面，在运行时它就会抛出空指针错误。

在 forwardRef() 方法的帮助下，实际上也可以先定义组件，具体说明见这篇博客。

但是为什么要先给自己找麻烦呢？还是通过在独立的文件中定义组件和服务，完全避免此问题吧。