依赖注入

问题的起点

代码需要其他代码。一个类需要另一个类，一个模块需要另一个模块。这是软件开发的基本事实。

传统的做法是：当你需要什么，就在内部创建它。需要一个数据库连接？在构造函数里 new Database()。需要一个日志记录器？直接实例化 Logger。

这看起来很自然。但它带来了一个根本性的问题——你的代码决定了它依赖什么。

这个"决定权"看似无害，实际上锁死了你的选择。

控制的转移

依赖注入的核心不是"注入"，而是"控制反转"（Inversion of Control）。

你的类不再决定使用什么依赖。它只声明需要什么，然后由外部提供。

这个转移改变了权力结构。

原来是：类说"我要用 MySQL 数据库"。现在是：类说"我需要一个符合数据库接口的东西"。

区别在哪？前者是命令，后者是契约。

命令是刚性的，契约是柔性的。命令绑定了具体实现，契约只约定了行为。

解耦的真正含义

很多人说依赖注入能"解耦"。但解耦解的是什么？

不是让代码之间没有关系。代码必须有关系，否则它们无法协作。

真正解耦的是具体实现和使用者之间的绑定。

你的代码不需要知道数据库是 MySQL 还是 PostgreSQL。它只需要知道有一个对象能执行查询，能返回结果。

这个"不需要知道"不是无知，而是抽象。

抽象让你能在不改变使用者的情况下，替换具体实现。这就是灵活性的来源。

测试性的自然结果

依赖注入常被说成"让代码更容易测试"。但这不是它的目的，而是它的结果。

当你的类接受外部提供的依赖时，你自然可以在测试时提供一个模拟（Mock）对象。

不需要连接真实的数据库，不需要发送真实的邮件。你可以提供一个假的数据库，一个假的邮件服务。

这不是因为依赖注入"支持测试"，而是因为它从根本上改变了代码的结构。

好的设计自然带来好的测试性。 不是为了测试而设计，而是好的设计天然容易测试。

手动注入与框架注入

依赖注入有两种实现方式。

一种是手动注入。你在代码中显式地创建依赖，然后传递给需要它的对象。

const database = new PostgresDatabase(config);
const logger = new FileLogger('/var/log/app.log');
const userService = new UserService(database, logger);

另一种是框架注入。你声明依赖关系，框架自动解析和注入。

@Injectable()
class UserService {
  constructor(
    private database: Database,
    private logger: Logger
  ) {}
}

手动注入简单直接，但在大型应用中会变得繁琐。框架注入自动化了这个过程，但增加了学习成本和抽象层级。

选择哪种？取决于你的项目复杂度。

但无论选择哪种，核心原则不变——控制权在外部，不在内部。

生命周期管理

依赖注入不只是传递对象，还涉及对象的生命周期。

一个依赖应该每次都创建新实例（Transient），还是整个应用共享一个实例（Singleton），还是在某个范围内共享（Scoped）？

这个决策很重要。

数据库连接通常是单例，因为创建连接昂贵。HTTP 请求处理器通常是瞬时的，因为每个请求应该独立。

依赖注入框架通常提供生命周期管理能力。但即使手动注入，你也需要思考这个问题。

对象应该活多久？谁负责创建和销毁它？ 这些问题的答案塑造了你的应用架构。

框架只是工具

很多人学习依赖注入，是通过 Spring、Angular、Nest.js 这些框架。

这些框架提供了强大的依赖注入容器，自动解析依赖关系，管理对象生命周期。

但框架不是依赖注入本身。

依赖注入是一个设计原则。框架只是实现这个原则的工具。

理解原则比学习框架重要。因为原则是本质，框架是形式。形式会变，本质不会。

当你理解了为什么要转移控制权，为什么要依赖抽象，为什么要从外部提供依赖，你就能在任何语言、任何框架中应用依赖注入。

甚至不需要框架。

设计的本质

依赖注入揭示了软件设计的一个核心问题：谁控制什么。

传统的设计让每个组件控制自己的依赖。这看似自治，实则封闭。每个组件都是一个孤岛，难以改变，难以组合。

依赖注入反转了这个控制。组件不再控制依赖，而是声明需求。外部负责满足这些需求。

这个反转创造了灵活性。你可以组合不同的依赖，创造不同的配置，测试不同的场景。

软件的灵活性不是来自代码做了什么，而是来自代码不做什么。 依赖注入的价值，正是它让代码"不做"依赖的创建和管理。

最后

依赖注入不是一个技术技巧。它是一种思维方式。

它要求你思考边界。什么应该在内部，什么应该在外部。什么应该被控制，什么应该被开放。

这种思考超越了代码层面。它关乎系统的组织方式，关乎复杂性的管理方式。

当你习惯于从外部提供依赖，你会发现，很多设计问题变得更清晰。因为你在强迫自己思考：这个组件的真正职责是什么？它需要什么才能完成这个职责？

这个思考的过程，就是设计的过程。