DI框架的依赖解析本质：从JavaSpring到NestJS看DI实践

依赖注入（Dependency Injection，简称 DI）是现代软件架构（如 DDD、洁净架构、微服务）中最核心的设计原则之一，它解决的核心问题是：如何让类与类之间的依赖关系可控、可测试、可替换，从而实现低耦合、高内聚。

依赖注入要解决什么问题？

传统写法（紧耦合）：

public class OrderService {
    private PaymentService paymentService = new PaymentService(); // 直接 new
    private EmailService emailService = new EmailService();
    
    public void createOrder() {
        paymentService.pay();
        emailService.send();
    }
}

这种写法存在如下问题：

1. 无法替换实现（想换成支付宝支付、换成短信通知都很难）

2. 无法单元测试（new 出来的对象无法 mock）

3. 依赖隐藏在类内部，违背了“面向接口编程”

依赖注入写法（松耦合）：

public class OrderService {
    private final PaymentService paymentService;
    private final EmailService emailService;

    // 通过构造函数注入（最推荐）
    public OrderService(PaymentService paymentService, EmailService emailService) {
        this.paymentService = paymentService;
        this.emailService = emailService;
    }
}

如果一个类有 new 关键字创建了其他服务（尤其是非纯工具类），大概率就是坏味道。

几乎所有现代框架（Spring Boot、ASP.NET Core、NestJS、Laravel、Quarkus、Micronaut 等）都把 DI 作为一等公民，正是因为它是从根本上提升软件可维护性的基石。

如果你在做任何中大型项目，没有依赖注入基本等于没有架构。

依赖注入的三种主要方式

主流框架（Spring、.NET Core、Java EE、Laravel、NestJS 等）几乎都推荐构造函数注入。

DI的核心实现

DI核心实现包含：

1. IoC 容器（容器 registry）:存放所有绑定关系（Binding / Registration）

2. Provider（依赖提供者）:真正“创建对象”的函数/工厂

3. 依赖解析（dependency graph/ Resolver + Graph）:递归解析依赖图、处理循环依赖、生命周期管理

管是 Java 的 Spring、.NET 的原生容器、NestJS（TypeScript）、Go 的 Wire、Python 的 Injector，还是 Kotlin 的 Koin，它们在“核心实现”上几乎一模一样，都可以抽象为下面这 3 个模块：

IoC 容器（容器 registry）

容器内部维护一个 Map：

token → provider 实例
token → provider 工厂
token → provider class
token → 值

Spring DI 核心实现 = 一个巨大的 Map<Token → Provider>

• 一个递归的依赖图解析器

• 三级缓存 + BeanPostProcessor 扩展点

NestJS DI 核心实现 = 一个按 Module 分层的 Map<Token → Provider>

• 同样递归的依赖图解析器

• 三级缓存（直接禁止循环依赖）

手动实现一个极简 DI 容器

typescript示例：

class Container {
  registry = new Map();

  bind(token, provider) {
    this.registry.set(token, provider);
  }

  get(token) {
    const provider = this.registry.get(token);
    return new provider();  // 简化
  }
}

java示例：

public class SimpleContainer {
    private Map<Class<?>, Supplier<?>> registry = new HashMap<>();

    public <T> void register(Class<T> type, Supplier<T> supplier) {
        registry.put(type, supplier);
    }

    public <T> T resolve(Class<T> type) {
        Supplier<?> supplier = registry.get(type);
        if (supplier == null) throw new RuntimeException("No binding for " + type);
        
        return (T) supplier.get();
    }

    // 支持自动解析构造函数（反射实现）
    public <T> T createInstance(Class<T> type) throws Exception {
        Constructor<?> constructor = type.getConstructors()[0];
        List<Object> params = new ArrayList<>();
        for (Parameter param : constructor.getParameters()) {
            params.add(resolve(param.getType()));
        }
        return (T) constructor.newInstance(params.toArray());
    }
}

优先构造函数注入，其次使用属性注入（@Autowired field）（Spring 官方也推荐）

服务定位器（Service Locator）比直接 new 好一点，但仍是反模式，隐藏依赖

总结：“不要在类内部创建依赖，而是让外部把依赖传进来”

Provider（依赖提供者）

Provider = 告诉容器“怎么创建一个依赖”。

三种常见 provider 类型（Spring 与 NestJS 在 Provider 的分类上高度相似）：

Class Provider（类提供者，就是普通 Bean）

这是最常见、最推荐的方式。

• 提供一个 类，NestJS 容器会自动实例化它（通过构造函数注入其依赖）。

• 默认使用 单例作用域（Singleton scope）。

• 自动处理依赖图解析。

// email.service.ts
@Injectable()
export class EmailService {
  send() { console.log('Email sent'); }
}
class HandSomeMan {
  name = 'HAO';
}

class TestHandSomeMan {
  name = 'HAO';
}

// app.module.ts
@Module({
  providers: [EmailService], // 等价于 { provide: EmailService, useClass: EmailService }
  {
      provide: TodoService,
      useClass: process.env.NODE_ENV === 'production' ? HandSomeMan : TestHandSomeMan
  }
})
export class AppModule {}

对应spring

@Service
public class EmailService { ... }

Value Provider（值提供者）

这类型的 Provider 主要是用来：

• 提供常数 (Constant)。

• 将外部函式库注入到控制反转容器。

• 将 class 抽换成特定的模拟版本。

那要如何使用呢？在展开式中使用 useValue 来配置。这里以 app.module.ts 为例：

// app.module.ts
const config = { apiUrl: 'https://api.example.com', timeout: 5000 };

@Module({
  providers: [
    {
      provide: 'CONFIG',        // token（标识符）
      useValue: config,         // 直接提供值
    },
    {
      provide: AppService,
      useValue: {
        name: 'HAO'
      }
    }
  ],
})
export class AppModule {}

在其他服务中使用：

@Injectable()
export class ApiService {
  constructor(
  @Inject('CONFIG') private config: any
  private readonly appService: AppService
  ) {}
  
  @Get()
  getHello(): string {
    return this.appService.getHello();
  }
}

对应spring

@Configuration
public class AppConfig {
  @Bean
  public Map<String, Object> config() {
    Map<String, Object> map = new HashMap<>();
    map.put("apiUrl", "https://api.example.com");
    return map;
  }
}

或者使用 @Value 注入配置属性，但若要注入整个对象，通常用 @Bean 返回一个实例（类似 useValue）。

Factory Provider（@Bean 工厂方法）

通过一个 工厂函数 动态创建依赖实例。

• 适用于需要 条件创建、组合多个依赖、异步初始化 等复杂场景。

• 工厂函数可以注入其他 Provider（通过 inject 字段声明依赖）。

// 假设根据环境决定使用哪种日志服务
@Injectable()
export class ConsoleLogger {}
@Injectable()
export class CloudLogger {}

// 工厂函数
export const loggerFactory = {
  provide: 'LOGGER',
  useFactory: (config: any) => {
    return config.env === 'prod' ? new CloudLogger() : new ConsoleLogger();
  },
  inject: ['CONFIG'], // 声明工厂依赖的其他 providers
};

@Module({
  providers: [
    { provide: 'CONFIG', useValue: { env: process.env.NODE_ENV } },
    loggerFactory,
  ],
})
export class AppModule {}

类型的 Provider 使用工厂模式让 Provider 更加灵活，透过 注入其他依赖 来变化出不同的实例，是很重要的功能。使用** useFactory 来指定工厂模式的函数**，并透过** inject 来注入其他依赖**。

对应spring

@Bean
@ConditionalOnProperty(name = "app.env", havingValue = "prod")
public Logger cloudLogger() {
  return new CloudLogger();
}

@Bean
@ConditionalOnProperty(name = "app.env", havingValue = "dev")
public Logger consoleLogger() {
  return new ConsoleLogger();
}

或者使用 FactoryBean 接口实现更复杂的工厂逻辑。

依赖解析（dependency graph）

依赖解析（Dependency Resolution）是整个 DI 容器的“大脑”和“心脏”，它决定了一个 DI 框架到底是“玩具”还是“工业级”。

• Spring 是 DI 模式的先驱之一，其解析机制围绕 ApplicationContext（即 IoC 容器）和 Bean 定义展开。

• NestJS 使用的是一个名为 IoC 容器 的内部模块，其依赖解析机制高度依赖于 TypeScript 的元数据反射能力。

依赖解析的核心任务（任何语言的 DI 框架都必须干这 5 件事）

当容器需要实例化一个类 Class C 时，它首先需要知道Class C 依赖于哪些其他类或接口，容器需要：

1. 识别依赖 (Dependency Identification)

当容器需要实例化一个类 C 时，它首先需要知道 C 依赖于哪些其他类或接口。

实现方式：

• 构造函数扫描： 检查 C 的构造函数参数列表。

• 注解/装饰器扫描： 扫描类 C 上的特定注解（如 Spring 的 @Autowired，NestJS 的 @Injectable）或属性上的装饰器。

2. 查找映射 (Mapping Lookup)

对于识别出的依赖项 D，容器在自己的注册表 (Registry/Binding Map) 中查找，以确定应该使用哪个具体实现 $D'$ 来满足这个依赖。

实现方式： 

查找 D 到 D'的映射（例如，接口 UserService 映射到实现类 UserServiceImpl）。

3. 实例化依赖 (Instantiation)

一旦确定了具体实现 D，容器就需要创建它的一个实例。这是遵循生命周期规则的关键步骤。

实现方式：

• 单例 (Singleton): 如果 D是单例，容器会检查是否有已存在的实例。如果有，直接返回；如果没有，创建并缓存起来。

• 原型/请求作用域 (Prototype/Scoped): 每次请求都创建一个新的实例。

4. 递归解析 (Recursive Resolution)

如果依赖项  D  本身也有依赖（依赖图 D'->E, F），容器会递归地回到步骤 1，对 D' 的依赖进行解析，直到所有依赖链都被满足。

5. 注入 (Injection)

将所有已解析和创建的依赖实例传递给初始类 C，完成注入。

依赖解析实现：

Java Spring 的依赖解析全流程（工业级最复杂实现）

核心入口方法（简化版）：

// AbstractApplicationContext.refresh()
finishBeanFactoryInitialization() 
  → DefaultListableBeanFactory.preInstantiateSingletons()
      → getBean(name)
          → doGetBean()
              → createBean() 
                  → doCreateBean()   ← 真正干活的地方

doCreateBean() 里依赖解析的真实顺序（极简版源码路径）：

protected Object doCreateBean(...) {
    // 1. 实例化（这里已经完成了构造函数注入！）
    InstanceWrapper wrapper = createBeanInstance(beanDefinition, beanName, args);
        → ConstructorResolver.autowireConstructor()   // 解析构造函数 + 递归 getBean 参数

    // 2. 提前暴露半成品（三级缓存关键步骤）
    addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));

    // 3. 属性填充（字段注入 + setter 注入）
    populateBean(beanName, mbd, instanceWrapper);
        → AutowiredAnnotationBeanPostProcessor
        → CommonAnnotationBeanPostProcessor (@Resource)

    // 4. 初始化回调（Aware → @PostConstruct → InitializingBean → init-method）
    initializeBean(beanName, exposedObject, mbd);

    // 5. 再次检查循环引用，替换早期引用
    getEarlyBeanReference → AOP 代理在这里生成（三级缓存的意义）
}

Spring 依赖解析最牛的 3 个设计：

1. 构造函数注入在实例化阶段就完成（createBeanInstance）

2. 三级缓存 + 早期引用暴露完美解决单例循环依赖

3. 所有扩展（AOP、@Transactional、@Async）都在 BeanPostProcessor 阶段完成，解析阶段完全干净

NestJS 的依赖解析全流程（极简 + 现代 + 激进）

NestJS 依赖解析的核心类只有这几个（路径：packages/core/injector）

InstanceLoader.createInstancesOfDependencies()          // 入口
  → container.getModules().forEach(module => 
        this.createInstancesOfModule(module))

    → injector.loadProvider()                             // 真正干活
        → injector.loadInstanceOfProvider(wrapper, module)
            → this.resolveParamDependencies(wrapper, module)  // 解析构造函数参数
                → this.resolveSingleParam(paramToken)         // 递归调用 container.get(token)
    
    → injector.loadMiddleware()...
    → injector.loadController()...

NestJS 依赖解析的真实顺序（极简版）：

1. 收集当前 Module 的所有 providers/controllers/guards...

2. 按依赖顺序排序（通过分析构造函数参数类型 + @Optional() @Inject() 自定义 token）

3. 对每个 provider：

1. 反射拿到 constructor 参数类型数组

2. 递归调用 container.get(token, { strict: false }) 拿到依赖实例

3. new Class(...dependencies) 创建实例

4. 如果是 USE_FACTORY 或 USE_VALUE，直接执行工厂函数

5. 把创建好的实例放入 wrapper.instance

4. 所有 provider 都创建完后，再创建 controller（因为 controller 依赖 provider）

NestJS 依赖解析的激进设计（和 Spring 完全相反的 3 点）：

直观对比表（一目了然）

所有 DI 框架的依赖解析本质都是递归 + 缓存 + 生命周期回调!

只是 Spring 为了兼容历史包袱搞出了三级缓存这套‘黑魔法’，而 NestJS 直接说‘我不救你，你自己写好’

• Spring 的依赖解析 = “最大兼容性 + 最大复杂性”→ 愿意用三级缓存、BeanPostProcessor、懒加载等一切手段来“救你”，代价是极其复杂。

• NestJS 的依赖解析 = “极简 + 现代 + 强制最佳实践”→ 直接一次性把依赖图解析完，不救循环依赖、不懒加载、不让你乱用属性注入，强迫你写出干净的树形依赖。

参考文章：
Nest-Provider 建立实例的原理与Provider的种类你都了解吗？ https://juejin.cn/post/7096149001308733448

Nestjs 框架教程（第四篇：Providers） https://keelii.com/2019/07/04/nestjs-framework-tutorial-4

万字长文，讲透彻 NestJS 的设计模式 - 有梦想的程序猿的文章 - 知乎 https://zhuanlan.zhihu.com/p/690935654

转载本站文章《DI框架的依赖解析本质：从JavaSpring到NestJS看DI实践》,
请注明出处：https://www.zhoulujun.cn/html/webfront/server/nestjs/9705.html