老规矩，先说说我为什么会琢磨这么个玩意儿。前阵子接手一个小型服务，代码量不大，但每次加一个新功能，都得手动改一堆初始化逻辑。A依赖B，B依赖C，C手里还有一堆配置参数，一个模块没接上，整个服务跑起来就给你抛个空指针。当时心里就在想，这要是有一个统一管理对象创建和依赖关系的容器，是不是就能省下一堆事？于是就有了“简单依赖注入容器”这个小项目，严格来说它不算一个完整框架，更像是我从需求出发自己做的一个轻量工具，但做完之后，整个服务的初始化代码确实清爽了很多。
如果你是刚接触后端没多久、对各种“容器”“IoC”概念只听了个名字就头疼的开发者，又或者你已经在用成熟框架但一直好奇框架后面到底做了什么，这篇文章应该能帮到你。我会从一个最简单的角度切入，带你手写一个迷你的依赖注入容器，把它从设计到实现再到踩坑全过程讲清楚。这篇文章不会去复刻那些动辄几万行的框架，只解决一个问题：如何用一个小而美的容器，把对象依赖从混乱无序变成清晰可控。
1. 先搞清楚依赖注入到底在解决什么问题
1.1 没有容器的时候，代码是怎么写的
很多刚学编程的朋友都会觉得：我直接在一个类里面new另一个类，用起来不也挺方便吗？确实，在小项目里这种写法完全没毛病。问题是，一旦项目规模上来，你可能会遇到这些情况：
- 某个类需要换一个实现，比如把A类的实现从A1换成A2，你得挨个找到所有new A1的地方修改。
- 某个类构造参数变了，比如原来需要两个参数，现在需要三个，所有new它的地方全都得跟着改。
- 单元测试很痛苦，你没法轻易替换成Mock对象，因为大家都new死了。
这个问题的本质是“控制权”不在你手里，而在各个类自己手里。每个类都亲自创建它需要的东西，耦合自然就高了。反过来，如果一个类只声明“我需要什么”，而由外部统一决定怎么写、怎么传，那这个类就变得非常好测试，也很好维护。这套思路在业界被叫做控制反转（IoC），而依赖注入（DI）正是实现IoC的一种常见方式。
1.2 容器解决的是“创建和装配”这个脏活
我们的依赖注入容器，说白了就是一个专职负责“创建对象”和“按依赖关系组装对象”的工厂。你问它要一个订单服务，它会去看这个服务依赖了哪些东西，先把这些依赖创建出来，再组装成你要的服务返回给你。
这里有个最关键的设计选择：为什么我们老提到“构造器注入”？因为构造器可以保证对象在被创建之后，它需要的依赖是绝对完整、绝对可用的。你想想，如果一个对象创建出来了，但依赖还是null，那你还得记得去调setter给它赋值，一旦忘了，运行期就会出问题。构造器注入不搞这套“先建后填”的操作，它把需求的声明放在最显眼的地方，缺了任何一个依赖，对象根本创建不出来。所以，容器的核心目标之一，就是保证“能创建出来的对象，一定是状态完备的”。
1.3 简单容器的设计边界
虽然市面上像Spring这样的大型框架提供了很多高级功能，但回到“简单依赖注入容器”这个目标上，我给自己定了几条设计边界：
- 只解决单例和原型这两种最常见作用域，不搞Session、Request这些花活。
- 通过注册表明确声明绑定关系，不搞无脑扫描那一套，保持代码显式可控。
- 尽量零依赖，不用额外的第三方库，这样每个人拿到代码都能直接编译运行。
- 循环依赖能用setter缓解就缓解，但构造器之间循环依赖直接报错，坚决不静默处理。
这个取舍很重要。很多新手在写自己的容器时会贪心，什么都想实现，结果代码写了一堆，核心的“注册→解析→注入”链路反而被垃圾代码淹没。简单的意思是：能用最少的代码把核心机制说清楚，而不是把所有功能都塞进去。
2. 核心机制拆解：从接口到容器的演变
2.1 先定义服务接口和实现类
任何依赖注入都离不开“接口和实现分离”这个前提。给一个简单例子，假设我们有一个通知服务，它要用不同的方式发送消息。我会定义一个接口，然后给两套实现：
// 通知服务接口 export interface Notifier { send(message: string): void; } // 邮件实现 export class EmailNotifier implements Notifier { send(message: string) { console.log(`[Email] ${message}`); } } // 短信实现 export class SmsNotifier implements Notifier { send(message: string) { console.log(`[SMS] ${message}`); } }这里有个容易踩的坑：很多人在没容器的时候，就算有接口也还是会在业务类里写死具体实现。比如业务类直接“new EmailNotifier()”，那接口就白建了。要真正享受依赖注入的福利，业务类必须只声明“我需要Notifier”，而不是“我需要EmailNotifier”。从这个时候开始，你已经把控制权交给外部了，具体要哪个实现，由容器决定。
2.2 三种依赖绑定的主流做法
依赖注入容器通常有三种绑定方式，各有侧重：
手动编码绑定：直接在代码里调用容器的bind方法，告诉它“这个接口对应那个实现”。这种方式最简单直白，适合小项目，我们这篇文章用的就是这个。
配置文件绑定：在XML或JSON里写绑定关系。好处是改绑定不用重新编译代码，但维护成本高，找错误很麻烦。Spring早期就是这样的风格，现在大家其实不太喜欢这种啰嗦的方式。
注解自动绑定：在实现类上用注解标注“我是这个接口的实现类”，容器在启动时扫描并自动注册。这种方式写起来最方便，但需要额外实现类扫描机制，并且隐式绑定多了以后会让项目变得不太好追溯。
三者的取舍可以用一个简单类比：手动编码绑定就是你把食材清单列清楚，买什么、买多少一目了然；配置文件绑定像是你把清单交给别人帮你买，省事但对方买错你很难查；注解自动绑定则是直接雇了个管家，只要说“今天缺啥自己看着办”，效率高，但你需要足够信任这个管家的判断力。
2.3 绑定内部存储结构
容器的内部其实就是一个Map（更准确地说是注册表）。我们用一个类型作为键，一个“创建工厂函数”作为值。流程是：
container.bind(Notifier).toDynamicValue(() => new EmailNotifier());容器不需要关心键的实现长什么样，它只需要知道“接口Notifier对应的工厂函数是哪一个”。调用resolve的时候，取出工厂函数执行一下，返回实例。就这么简单。
这里要注意，容器内部存的是工厂函数而不是实例对象。为什么？因为只有存工厂函数，才能灵活控制创建时机和创建次数。如果绑定的时候就把实例创建好，那就没法实现“每次调用都创建一个新实例”的原型作用域；如果你希望它单例，也可以在工厂函数外面套一层缓存，确保只执行一次。一鱼两吃，灵活度全在这个设计细节里。
3. 从零手写一个最小可运行的容器
3.1 构建基础注册表
容器代码我选TypeScript来实现，因为类型定义能帮我们理解接口、抽象类这些概念。先看核心数据结构：
type Token<T> = Function & { prototype?: T }; class Container { private bindings = new Map<Token<any>, () => any>(); bind<T>(token: Token<T>): Binder<T> { return new Binder(this, token); } resolve<T>(token: Token<T>): T { const factory = this.bindings.get(token); if (!factory) { throw new Error(`No binding found for ${token.name}`); } return factory(); } // 内部方法，Binder 调用 setBinding<T>(token: Token<T>, factory: () => T) { this.bindings.set(token, factory); } }这里有个知识点：Token本质上是我们用“类型”当成了Map的键。TypeScript的类在运行时是一个函数对象，所以它可以作为ES Map的键使用。有人可能会问，为什么不用字符串当键？字符串当然也可以，但会丢失类型信息。比如你resolve("notifier")拿到的是什么类型，容器自己都不知道。用类型当Token，在编译期就能检查出resolve的返回类型，这是现代DI容器比较常见的做法，也是我们坚持用类型Token而不是字符串Token的原因。
你可能还会注意到，resolve方法的错误处理其实很关键。抛出明确异常“找不到绑定”，比返回undefined好一万倍。因为依赖缺失如果藏着掖着，最后要么是空指针，要么是类型错误，查起来更痛苦。不如在起点就大声喊出来。
3.2 Binder需要支持哪些能力
光有基础容器还不够，我们还需要一个流畅的API来表达“如何创建实例”。Binder类是连接外部配置和容器的桥梁：
class Binder<T> { constructor(private container: Container, private token: Token<T>) {} to(impl: new () => T) { this.container.setBinding(this.token, () => new impl()); return this; } toDynamicValue(factory: () => T) { this.container.setBinding(this.token, factory); return this; } asSingleton() { const originalFactory = this.container.getBinding(this.token); let instance: T | null = null; this.container.setBinding(this.token, () => { if (instance === null) { instance = originalFactory(); } return instance; }); return this; } }踩过的坑提示：asSingleton的实现一定要存放原始工厂，而不是直接set一个全新的工厂进去覆盖。如果你在调用asSingleton前没拿到原始工厂，而是在里面又调一次bindings.get，万一没绑定就会出意外。另外，单例缓存放在外层，让容器自己持有这个变量，保证同一个容器实例下，同一个Token只创建一个实例。
为什么说单例的“实例变量”放在Binder方法里就能生效？因为闭包。asSingleton方法里的instance变量并不随着方法调用结束而消失，它被返回的新工厂函数一直引用着。这是JavaScript/TypeScript的闭包特性，简单但实用。
3.3 自动解析依赖的进阶思考
前面这些只能算“手动创建工厂”，还不太像一个真正的DI容器。真正的依赖注入应该能自动看懂“构造器需要什么”。我们需要通过反射来读取构造函数的参数。
在JavaScript里，可以通过Function.prototype.toString拿到函数的源代码，再用正则提取参数名：
function getParamNames(fn: Function): string[] { const fnStr = fn.toString(); const paramsMatch = fnStr.match(/constructor\s*\(([^)]*)\)/); if (!paramsMatch) return []; return paramsMatch[1] .split(",") .map((p) => p.trim()) .filter((p) => p.length > 0); }拿到参数名之后，容器解析一个类的时候，会先看它的构造器有什么参数，然后根据参数名找到对应的绑定，递归创建依赖。听起来是不是很优雅？但这里面有个很大的坑，我后面会单独讲。要知道JavaScript的反射能力受限，如果你用压缩工具混淆代码，参数名可能从userRepository变成a，这时容器就彻底蒙圈了。所以，简单容器更推荐结合装饰器或者显式声明元数据，把参数名和Token类型对起来，而不是纯靠字符串猜。
3.4 完整使用示例
把上面的组件串起来，看看实际是怎么用的：
interface Config { apiBaseUrl: string; } class AppContext { private container = new Container(); configure() { this.container.bind(Config).toDynamicValue(() => ({ apiBaseUrl: "https://api.example.com", })); this.container.bind(Notifier).to(EmailNotifier).asSingleton(); this.container.bind(OrderService).to(OrderService); } get<T>(token: Token<T>): T { return this.container.resolve(token); } } // 使用 const context = new AppContext(); context.configure(); const orderService = context.get(OrderService);注意OrderService这类业务类，我们不需要手动声明它依赖什么，容器在resolve它的时候会读取构造器参数，然后继续往下解析。如果我把OrderService的构造函数写成constructor(private notifier: Notifier, private config: Config)，那么容器就会自动把Notifier和Config都创建好再组装。
实际跑起来的时候你会发现一个细节：bind(Config).toDynamicValue(...)返回的配置对象，每次解析都是新创建的吗？如果是单例模式呢？这里最简单的做法是把配置对象也注册成单例，避免每次解析都创建一个新对象，导致配置修改后所有依赖它的对象同时变化。
3.5 作用域：单例还是原型
很多初学者不太理解“作用域”在容器里的含义。其实很简单，它决定了一次resolve返回的到底是不是同一个对象。
- 单例（Singleton）：同一个Token，在同一个容器内，无论调多少次resolve，返回的都是同一份实例。
- 原型（Prototype）：每次resolve都重新创建一个新实例，彼此之间互不影响。
实际业务里两种场景随处可见。比如一个无状态的Repository，通常用单例，避免频繁创建对象带来的开销；而某个带状态的服务，比如“当前用户会话”，就应该用原型，每次拿到的都是独立的会话对象。我在容器里通过asSingleton方法实现单例，默认都是原型。
这里还有一个优化细节，就是单例的“懒加载”。很多新手会把单例理解为容器创建时就立刻把实例建好，其实没必要。我们的做法是第一次resolve时再创建，之后每次复用的都是同一个实例。这样可以减少启动时间，也避免依赖还没准备好就初始化了对象，一举两得。
4. 模拟实战：从注册到组装订单服务
4.1 模拟业务背景
为了让整个流程落地，我用一个非常典型的场景举个例子：一个订单服务，它需要使用订单仓库来存储数据，并且通过通知服务通知用户下单结果。
export class OrderRepository { save(orderId: string) { console.log(`Saved order: ${orderId}`); } } export class OrderService { constructor( private repo: OrderRepository, private notifier: Notifier ) {} placeOrder(orderId: string) { this.repo.save(orderId); this.notifier.send(`Order ${orderId} placed!`); } }可以看到，OrderService完全不知道CreateNotifier这些类的存在，它只声明了两个依赖。接下来就是容器大显身手的时候了。
4.2 注册依赖并启动容器
容器配置代码和之前类似，但你可以看到组装的顺序和依赖关系：
const container = new Container(); container.bind(OrderRepository).to(OrderRepository).asSingleton(); container.bind(Notifier).to(EmailNotifier).asSingleton(); container.bind(OrderService).to(OrderService); const orderService = container.resolve(OrderService); orderService.placeOrder("10086");执行resolve(OrderService)的时候，容器内部发生的事情大致是这样：
- 从绑定表查OrderService的工厂函数。
- 工厂函数被调用，读取构造器参数，得到
repo和notifier。 - 先解析OrderRepository，发现它有单例缓存，直接返回缓存的实例（第一次解析就创建并缓存）。
- 再解析Notifier，同理得到EmailNotifier实例。
- 把两个依赖传入OrderService构造函数，完成创建。
整个过程看起来平平无奇，但这就是依赖注入最容易理解的一个例子。你可能注意到OrderService并没有被注册成单例，所以每次resolve都会生成新实例；而OrderRepository和Notifier是单例，所有OrderService实例共享同一个Repository和Notifier，这正好符合实际业务需要。
4.3 参数选择与容器启动顺序的坑
这里重点说明一个新手极容易踩的坑：绑定顺序重要吗？
在我的设计里，绑定顺序完全不重要，因为容器只是往注册表里放工厂函数，并不立即创建实例。但是如果你用了“启动时校验所有依赖是否完整”的功能（类似Spring容器的启动检查），绑定的顺序就会影响校验的先后。简单容器一般不做这种检查，而是等真正resolve的时候才报错。这样有一个好处，就是“用不到的服务不启动，启动速度更快”，但也有一个坏处，就是“错误可能会延迟到运行期才暴露”。
如果你想要启动时立刻检查所有绑定是否正确，可以加一个validateAll方法，遍历注册表并把每个工厂函数都执行一次，但如果里面有原型模式且带有副作用，这就会导致不必要的对象创建。所以我的建议是：简单容器不做全局启动校验，用resolve时按需创建，保持简单可靠。要快速验证配置没问题，直接在应用启动时手动resolve一次核心入口类即可。
4.4 从零实现的最小完整代码
这里给出一个不算很长但能跑起来的最小实现，方便你把前面的思路串起来：
type Token<T> = Function & { prototype?: T }; class TinyContainer { private factories = new Map<Token<any>, () => any>(); bind<T>(token: Token<T>) { return { to: (Impl: new () => T) => { this.factories.set(token, () => new Impl()); }, toDynamicValue: (factory: () => T) => { this.factories.set(token, factory); }, toSingleton: (Impl: new () => T) => { let instance: T | null = null; this.factories.set(token, () => { if (!instance) instance = new Impl(); return instance; }); }, }; } resolve<T>(token: Token<T>): T { const factory = this.factories.get(token); if (!factory) { throw new Error(`No binding for ${token.name}`); } return factory(); } } export { TinyContainer, Token };写完之后你会发现，核心代码量非常少，但已经能覆盖中小项目的绝大多数需求。这正体现了“简单”二字的含义：用最少的设计实现必要的功能，而不是总想复制一个大而全的框架。
5. 循环依赖与问题排查实录
5.1 循环依赖到底怎么发生的，一台单例引发的灵异事件
前面所有内容建立在一个前提下：依赖关系是单向的，A依赖B，B不依赖A。但现实世界总有例外。我遇到过一个特别典型的循环依赖问题，发生在A依赖B，B依赖C，C又依赖A的路上。表面看起来每个类写的都没问题，但一启动就抛“栈溢出”或“找不到绑定”的错误。
为什么会出现循环依赖？最直观的解释是你用构造器注入，A的构造器需要B，B的构造器需要C，C的构造器又需要A，整个解析就变成了一个无限递归的套娃。你得一直创建下去，直到栈爆掉。
一种解决办法是改用Setter或属性注入。a. 先创建A实例（此刻A的属性还是空的），b. 创建B实例，c. 创建C实例，d. 把A赋给C的属性，e. 把B赋给A的属性。这样最终所有对象都创建完成。但是构造器注入不行，因为实例还没创建出来，没法引用。
5.2 简单容器的循环依赖处理方案
我自己的简单容器没有实现特别复杂的“三级缓存”，也不打算做那么复杂。我的建议是采取两条腿走路：
第一，对于简单的A即B又要B即A的情况，改造其中一方的注入方式，把构造函数注入改成Setter注入，容器在创建对象后把这个依赖补上。这个方式实现成本低，并且很容易理解，对大多数人够用了。
第二，在容器内部维持一个“创建中”的标记，结合动态代理临时占位，这样A在构造时拿到的B是一个代理，等整个依赖链全部创建完，代理再把真正的方法调用转发给已经就绪的B实例。这个方式实现起来会复杂一些，但它能让代码保持构造器注入的统一性，不需要改业务类。对于“简单依赖注入容器”这个定位，我更推荐第一种，因为开发速度和可读性更重要。
5.3 常见异常速查表
| 错误现象 | 可能原因 | 解决办法 |
|---|---|---|
| 启动时抛“No binding found” | 忘记注册某个服务，或者服务名拼写错误 | 检查所有依赖类的bind调用，确保已经注册对应Token |
| 启动时抛“Cannot instantiate abstract class” | 把接口或抽象类当做了普通实现去to()绑定 | 把to()绑定改成具体实现类，或者改用toDynamicValue返回具体实现 |
| 运行时无限递归，堆栈溢出 | 存在循环依赖，且双方都使用构造器注入 | 将其中一方改为Setter注入，或调整设计消除循环依赖 |
| 每次获取实例，状态都不一致 | 忘记用asSingleton，导致每次都是新实例 | 根据业务需要，给无状态服务加单例作用域 |
| 参数名被压缩，reflect解析失败 | 使用了代码压缩工具，函数参数名被重命名为a、b | 避免依赖JS压缩参数名，改用装饰器或显式元数据标记 |
| 容器启动慢 | 每次resolve都重新执行反射读参数名 | 缓存各Token的参数信息，或改用工厂函数手动声明依赖 |
上面这张表是我实际调试中整理出来的，可以说基本覆盖了手写DI容器时90%会遇到的典型问题。
5.4 定位问题的调试套路
调试DI容器和调试普通业务代码有些不一样，你不能只盯着出错的类，得从“依赖链”的角度看问题。我排错一般会这样操作：
- 先打印异常栈，定位到是哪个Token解析失败。
- 在该Token的resolve处打断点，观察内部绑定的工厂是否存在。
- 手动在代码里模拟new过程，确认构造器参数是否都能拿到。
- 如果是循环依赖，会看到方法调用栈是一层套一层，并且重复出现相同Token，这时候立刻能确定是哪条依赖链出问题。
一个小技巧：在容器里给每个Token加上toString方法，让它在日志中打印出当前解析的链，这样调试起来非常直观。比如日志输出：
Resolving: OrderService Resolving: OrderRepository Resolving: Notifier一眼就知道当前解到哪一步了，再也不用对着堆栈猜来猜去。
6. 简单容器背后的工程决策：什么时候该自己写，什么时候该用框架
6.1 自己写容器的价值在哪里
写了这个简单容器之后，我最深的一个感受就是：它能帮你真正理解那些大型框架在设计时做的重要决策。比如为什么Spring要用三级缓存处理循环依赖？为什么有的框架不推荐字段注入？这些问题在文档里看一百遍，都不如自己写一遍容器机制来得透彻。
你还能收获一个非常实际的技能：轻量场景里根本不用引框架。前阵子我做一个内部测试工具，总共十几个类，如果引入一个大型DI框架，光配置环境就比业务代码还繁琐。用我自己写的这个小容器，注册十几行代码解决所有依赖组装，轻装上路，非常爽。
6.2 什么情况下别自己写容器
自己写容器也有明显的适用边界。如果你面临这几个场景，我还是会建议直接用成熟框架：
- 项目规模很大、模块很多，需要扫描大量类并自动组装依赖。
- 需要AOP拦截、事件机制、多个环境配置文件等复杂能力。
- 团队里所有人都熟悉框架，使用框架能降低沟通成本。
- 需要成熟的生态和文档，而不是维护自己的“玩具代码”。
总而言之，自己写容器的过程是一次绝佳的学习方式和轻量选择，但生产环境里如果已经有标准框架，没必要重复造轮子。有人可能担心这个项目太“小而美”没有炫耀价值，但在我看来，学习价值远比炫技价值重要。我后来把这个容器的思路用在了好几个小型工具和测试框架里，大大减少了样板代码，这就是它带来的直接回报。
6.3 后续扩展的想象空间
虽然叫“简单依赖注入容器”，但这套核心结构其实还可以继续往下扩展。常见的扩展方向包括：支持按名称绑定多个实现并在运行时选择需要的实现、增加对象销毁时的清理钩子、以及支持异步工厂函数来配合数据库连接池这类资源型依赖。
我个人的建议是：先把这个核心跑通、跑稳，再按实际需求加功能，不要一开始就想着搞大而全的设计。等到你的需求真正冒出来的时候，再动手加也不迟，而且那时你会更清楚改动会牵动哪些模块。
说到底，代码简约，逻辑清晰，才是“简单”这两个字最大的价值。
