用TypeScript手写IOC容器：5分钟彻底理解依赖注入

最近在技术社区看到不少关于IOC和DI的讨论，发现很多初学者虽然能背出"控制反转"和"依赖注入"的定义，但一到实际项目还是习惯性地new对象。这让我想起自己刚开始学习时的困惑——那些高大上的概念解释，远不如亲手写一个迷你容器来得透彻。今天我们就用TypeScript从零构建一个简化版NestJS容器，通过代码对比让你真正理解解耦的艺术。

1. 为什么我们需要IOC容器

想象这样一个场景：你正在开发一个电商系统， OrderService 需要依赖 PaymentService 来处理支付逻辑。传统写法可能是这样的：

class PaymentService {
  process(amount: number) {
    console.log(`Processing $${amount} payment`);
  }
}

class OrderService {
  private paymentService: PaymentService;
  
  constructor() {
    this.paymentService = new PaymentService();
  }
  
  checkout(amount: number) {
    this.paymentService.process(amount);
  }
}

这种写法存在几个明显问题：

• 紧耦合 ： OrderService 直接实例化 PaymentService ，两者紧密绑定
• 难以测试 ：无法在测试时替换 PaymentService 的实现
• 扩展困难 ：想改用其他支付服务必须修改 OrderService 代码

依赖注入 正是为了解决这些问题而生。它的核心思想很简单： 不要自己new依赖对象，让外部传给你 。改进后的版本：

class OrderService {
  constructor(private paymentService: PaymentService) {}
  
  checkout(amount: number) {
    this.paymentService.process(amount);
  }
}

现在依赖关系变得更清晰了，但问题来了：谁负责创建和组装这些对象？这就是 IOC容器 的用武之地。

2. 实现一个迷你IOC容器

让我们从零开始构建一个极简容器，只需要不到50行代码：

type Constructor<T = any> = new (...args: any[]) => T;

class Container {
  private providers = new Map<string, any>();
  
  // 注册提供者
  register<T>(token: string, provider: T): void {
    this.providers.set(token, provider);
  }
  
  // 解析依赖
  resolve<T>(token: string): T {
    const provider = this.providers.get(token);
    
    if (provider === undefined) {
      throw new Error(`No provider found for ${token}`);
    }
    
    // 如果是类，自动实例化
    if (typeof provider === 'function') {
      return this.instantiate(provider);
    }
    
    return provider;
  }
  
  // 实例化类并注入依赖
  private instantiate<T>(ctor: Constructor<T>): T {
    // 获取构造函数参数类型
    const paramTypes: Constructor[] = 
      Reflect.getMetadata('design:paramtypes', ctor) || [];
    
    // 递归解析所有依赖
    const dependencies = paramTypes.map(type => {
      // 使用类型名作为token
      const token = type.name;
      return this.resolve(token);
    });
    
    return new ctor(...dependencies);
  }
}

这个容器的核心功能：

1. 注册机制 ：通过 register 方法绑定标识符(token)与提供者(provider)
2. 依赖解析 ： resolve 方法根据token查找并返回对应的实例
3. 自动注入 ：遇到类构造函数时，递归解析所有参数依赖

3. 实战：用容器管理电商系统

让我们用这个容器重构之前的电商系统：

// 启用TypeScript的反射元数据
import 'reflect-metadata';

// 定义服务
class PaymentService {
  process(amount: number) {
    console.log(`Processing $${amount} payment`);
  }
}

class OrderService {
  constructor(private paymentService: PaymentService) {}
  
  checkout(amount: number) {
    this.paymentService.process(amount);
  }
}

// 初始化容器
const container = new Container();

// 注册服务（可以替换为其他实现）
container.register('PaymentService', PaymentService);
container.register('OrderService', OrderService);

// 获取OrderService实例（自动注入PaymentService）
const orderService = container.resolve<OrderService>('OrderService');
orderService.checkout(100); // 输出: Processing $100 payment

关键改进点：

• 解耦 ： OrderService 不再关心 PaymentService 如何创建
• 可测试 ：可以注册Mock实现进行单元测试
• 可扩展 ：更换支付服务只需修改注册代码

4. 进阶：支持接口与多实现

实际项目中我们更倾向于依赖抽象而非具体实现。让我们扩展容器以支持接口：

// 定义接口
interface IPaymentService {
  process(amount: number): void;
}

// 实现接口
class AlipayService implements IPaymentService {
  process(amount: number) {
    console.log(`Alipay processing $${amount}`);
  }
}

class WechatPayService implements IPaymentService {
  process(amount: number) {
    console.log(`WeChat Pay processing $${amount}`);
  }
}

// 使用接口作为token
container.register('IPaymentService', AlipayService);

// 在构造函数中声明接口依赖
class OrderService {
  constructor(private paymentService: IPaymentService) {}
}

// 随时可以切换实现
container.register('IPaymentService', WechatPayService);

通过使用接口作为token，我们获得了更大的灵活性。NestJS的实际实现要复杂得多，但核心原理与我们这个迷你容器是一致的。

5. 对比：传统模式 vs IOC容器

为了更直观地理解IOC的价值，我们用一个表格对比两种方式：

特性	传统模式	IOC容器
耦合度	高（直接实例化依赖）	低（依赖外部注入）
可测试性	差（难以Mock）	好（轻松替换实现）
扩展性	差（需修改使用者代码）	好（只需修改容器配置）
代码复杂度	简单（直观）	较高（需要理解容器机制）
适用场景	小型项目/简单依赖	中大型项目/复杂依赖

提示：对于简单项目，引入IOC容器可能过度设计。但当项目规模扩大、依赖关系复杂时，IOC模式的优势会越来越明显。

6. 常见问题与解决方案

在实际使用中可能会遇到这些问题：

Q1：循环依赖怎么处理？
A：尽量避免，如果确实需要，可以使用属性注入或懒加载：

class A {
  @Inject()
  b: B; // 属性注入
}

Q2：如何管理生命周期？
A：可以扩展容器支持单例/瞬态模式：

container.register('Service', Service, { lifecycle: 'singleton' });

Q3：性能会有影响吗？
A：启动时会有额外开销（依赖解析），但运行时影响很小。对于性能敏感场景，可以考虑预编译依赖图。

7. 从迷你容器到NestJS

理解了基本原理后，再看NestJS的IOC实现就很容易了。NestJS的核心机制包括：

• 装饰器 ： @Injectable() 标记可注入类
• 模块系统 ： @Module 组织应用结构
• 作用域 ：支持请求级实例
• 高级特性 ：动态模块、自定义提供者等

我们的迷你容器已经实现了最核心的依赖注入功能。当你下次使用 @Inject() 装饰器时，就会明白背后发生了什么。