NestJS中依赖注入(DI)的底层运行机制及实现原理技术问询

Nest的DI系统完全基于reflect-metadata库 + TypeScript的装饰器元数据生成能力实现，解决了你提到的「TS类型只存在编译阶段」的问题，前提是你的tsconfig.json必须开启以下两个核心配置：

{
  "compilerOptions": {
    "experimentalDecorators": true,
    "emitDecoratorMetadata": true
  }
}

1. 编译阶段：类型元数据持久化 #

当你给类加上@Controller、@Injectable这类装饰器后，开启了emitDecoratorMetadata的TS编译器会自动给这些类注入元数据写入逻辑，编译后的JS代码里会包含类似以下逻辑：

// 编译后自动生成的隐形代码
Reflect.defineMetadata("design:paramtypes", [AppService], AppController);
Reflect.defineMetadata("design:paramtypes", [NewService], AppService);

其中design:paramtypes是固定的元数据key，对应的值就是构造函数参数的构造函数引用数组，这部分数据会完整保留到运行时，可以被JS代码直接读取。

2. 模块初始化阶段：Provider注册 #

当Nest启动解析@Module装饰器配置时，会把所有providers数组里的条目统一注册到当前模块的DI容器中：

• 简写的providers: [AppService]等价于完整配置{ provide: AppService, useClass: AppService }
• provide字段就是该Provider的唯一标识（Token），默认就是类本身的引用
• DI容器会维护一个Token到Provider实例/实例化规则的映射表，所有同模块下的控制器、Provider都可以通过Token访问到对应的实例

3. 实例化阶段：依赖递归解析注入 #

当Nest需要实例化某个控制器或Provider时，会执行以下固定逻辑：

1. 调用Reflect.getMetadata('design:paramtypes', 目标类)，拿到构造函数需要的参数Token数组
2. 遍历这个数组，到当前模块的DI容器中查找每个Token对应的Provider
3. 如果对应的Provider还没有实例化，就递归执行上述1-3的逻辑先实例化该Provider
4. 所有依赖都实例化完成后，按参数顺序把实例传入目标类的构造函数，生成目标类的实例

你的疑问直接解答 #

• 为什么Nest知道AppController需要AppService：实例化AppController时读取design:paramtypes拿到参数是AppService，去容器里找对应Token的Provider注入即可，完全不是按providers数组顺序注入
• 为什么加了NewService到providers后AppService可以直接用：只要AppService加了@Injectable装饰器，编译器就会生成它的构造函数参数元数据，实例化AppService时读取到它需要NewService，去容器里找到对应实例就会自动注入

特殊情况补充 #

如果用接口作为构造函数参数类型，因为接口编译后会完全消失，元数据里取不到对应的Token，这时候就需要手动用@Inject(Token)装饰器指定对应Provider的Token，这也是为什么接口类型依赖需要手动加@Inject的核心原因。

内容的提问来源于stack exchange，提问作者malcoauri