依赖注入不仅仅是一个让代码看起来“高级”的工具，它的核心价值在于解耦。通过将对象的“创建权”从业务逻辑中剥离并交给容器，我们能获得极高的灵活性。
关于依赖注入相关概念可参考依赖注入的艺术：编写可扩展 JavaScript 代码的秘密
以下是依赖注入最具代表性的五个使用场景。
1. 单元测试 (Unit Testing)
痛点： 当业务类直接 new 依赖时，测试该类就必须执行依赖的真实逻辑（如真实扣款、真实写库），导致测试缓慢且危险。
❌ 方式 A：不使用 InversifyJS (强耦合)
OrderService 内部强行依赖了 RealPayment。要测试 checkout 方法，你必须真的发起支付，无法轻松 Mock。
TypeScript
// 具体的支付实现
class RealPayment {
pay(amount: number) {
console.log(`$$$ 调用银行接口扣款: ${amount}`); // 真实副作用
}
}
class OrderService {
private payment: RealPayment;
constructor() {
// 😱 致命缺陷：硬编码依赖，测试时无法替换！
this.payment = new RealPayment();
}
checkout(amount: number) {
this.payment.pay(amount);
}
}
✅ 方式 B：使用 InversifyJS (依赖抽象)
业务类只依赖接口 IPayment。在单元测试中，我们可以通过容器绑定一个 MockPayment，轻松隔离副作用。
TypeScript
// 1. 定义接口
interface IPayment { pay(amount: number): void; }
// 2. 业务逻辑 (只依赖接口)
@injectable()
class OrderService {
constructor(
@inject(TYPES.Payment) private payment: IPayment // 注入接口
) {}
checkout(amount: number) {
this.payment.pay(amount);
}
}
// --- 单元测试文件 spec.ts ---
const testContainer = new Container();
// 🧪 测试时：绑定 Mock 实现
const mockPayment = {
pay: jest.fn() // 使用 Jest 等测试库的 Mock 函数
};
testContainer.bind(TYPES.Payment).toConstantValue(mockPayment);
testContainer.bind(OrderService).toSelf();
const service = testContainer.get(OrderService);
service.checkout(100);
// 断言：验证是否调用了 mock 方法，而不是真的扣款
expect(mockPayment.pay).toHaveBeenCalledWith(100);
2. 可替换的组件 (Swappable Components)
痛点： 同一个接口有多种实现（例如：存储策略既有本地存储，又有云存储）。传统写法通常伴随着大量的 if-else 或工厂模式代码。
❌ 方式 A：不使用 InversifyJS (工厂模式/条件判断)
调用者需要知道具体的实现类，且扩展新策略时需要修改工厂代码。
TypeScript
class LocalStorage { save() { console.log("存硬盘"); } }
class CloudStorage { save() { console.log("存 AWS S3"); } }
class FileManager {
private storage: any;
constructor(type: string) {
// 😱 违反开闭原则：每次加新策略都要改这里
if (type === 'local') {
this.storage = new LocalStorage();
} else {
this.storage = new CloudStorage();
}
}
}
✅ 方式 B：使用 InversifyJS (命名绑定)
使用 @named 标签，可以在不修改业务逻辑代码的情况下，灵活注入不同的策略。
TypeScript
@injectable()
class FileManager {
constructor(
// ✨ 优雅：同时注入两种策略，按需使用
@inject(TYPES.Storage) @named("local") private local: IStorage,
@inject(TYPES.Storage) @named("cloud") private cloud: IStorage
) {}
backup() {
this.local.save(); // 先存本地
this.cloud.save(); // 再存云端
}
}
// --- 容器配置 ---
container.bind<IStorage>(TYPES.Storage).to(LocalStorage).whenTargetNamed("local");
container.bind<IStorage>(TYPES.Storage).to(CloudStorage).whenTargetNamed("cloud");
3. 跨环境运行 (Cross-Environment Execution)
痛点： 开发环境用 SQLite，生产环境用 PostgreSQL。如果不使用 DI，代码中会充斥着 process.env.NODE_ENV 的判断，导致代码混乱。
❌ 方式 A：不使用 InversifyJS (环境判断污染逻辑)
TypeScript
class DatabaseService {
constructor() {
// 😱 环境配置逻辑泄漏到了业务类中
if (process.env.NODE_ENV === 'production') {
this.connection = new PostgresConnection();
} else {
this.connection = new SqliteConnection();
}
}
query() {
return this.connection.exec("SELECT * FROM users");
}
}
✅ 方式 B：使用 InversifyJS (容器模块化配置)
业务代码完全干净，环境切换的逻辑被移到了容器配置层（Composition Root）。
TypeScript
// 1. 业务代码 (完全不知道当前是什么环境)
@injectable()
class DatabaseService {
constructor(@inject(TYPES.DbConnection) private conn: IDbConnection) {}
}
// 2. 环境配置模块 (config.ts)
const devModule = new ContainerModule((bind) => {
bind<IDbConnection>(TYPES.DbConnection).to(SqliteConnection);
});
const prodModule = new ContainerModule((bind) => {
bind<IDbConnection>(TYPES.DbConnection).to(PostgresConnection);
});
// 3. 入口文件 (index.ts)
const container = new Container();
if (process.env.NODE_ENV === 'production') {
container.load(prodModule); // 🏭 加载生产模块
} else {
container.load(devModule); // 🛠️ 加载开发模块
}
4. 插件式架构 (Plugin Architecture)
痛点： 系统核心需要加载第三方插件。如果不使用 DI，核心系统必须手动 import 并实例化插件，这使得动态扩展变得极其困难。
❌ 方式 A：不使用 InversifyJS (手动列表)
核心代码必须“认识”每一个插件。
TypeScript
import { GitPlugin } from "./plugins/git";
import { DockerPlugin } from "./plugins/docker";
class App {
private plugins: any[] = [];
constructor() {
// 😱 扩展性差：想加个插件，还得改核心代码的构造函数
this.plugins.push(new GitPlugin());
this.plugins.push(new DockerPlugin());
}
run() {
this.plugins.forEach(p => p.exec());
}
}
✅ 方式 B：使用 InversifyJS (多重注入 Multi-Injection)
核心系统定义接口，插件自行注册到容器。核心系统自动获取所有符合接口的插件。
TypeScript
// 核心系统
@injectable()
class App {
private plugins: IPlugin[];
constructor(
// ✨ 魔法：自动把容器里所有绑定为 TYPES.Plugin 的实例都注入进来，形成数组
@multiInject(TYPES.Plugin) plugins: IPlugin[]
) {
this.plugins = plugins;
}
}
// 插件 A (独立文件)
bind<IPlugin>(TYPES.Plugin).to(GitPlugin);
// 插件 B (独立文件)
bind<IPlugin>(TYPES.Plugin).to(DockerPlugin);
// 这种模式下，新增插件只需要 bind 一下，不需要修改 App 类的任何代码。
5. 复杂的生命周期管理 (Singleton vs Transient)
痛点： 某些对象（如缓存、数据库连接池）必须是全局单例，而某些对象（如 HTTP 请求上下文）必须每次新建。手动管理这些单例模式非常容易出错。
❌ 方式 A：不使用 InversifyJS (手动单例模式)
开发者必须手动实现 Singleton 模式，代码啰嗦且难以维护。
TypeScript
class CacheService {
private static instance: CacheService;
// 😱 样板代码：每个单例类都要写这一坨逻辑
private constructor() {}
public static getInstance(): CacheService {
if (!CacheService.instance) {
CacheService.instance = new CacheService();
}
return CacheService.instance;
}
}
// 使用时必须小心
const cache = CacheService.getInstance();
✅ 方式 B：使用 InversifyJS (声明式生命周期)
类本身不需要知道自己是不是单例，全靠容器配置。
TypeScript
@injectable()
class CacheService {
constructor() { console.log("CacheService Created"); }
}
@injectable()
class RequestHandler {
constructor() { console.log("RequestHandler Created"); }
}
// --- 容器配置 ---
// 1. 单例：整个应用只创建一次
container.bind(CacheService).toSelf().inSingletonScope();
// 2. 瞬态：每次请求都创建新的
container.bind(RequestHandler).toSelf().inTransientScope();
// --- 运行结果 ---
const cache1 = container.get(CacheService);
const cache2 = container.get(CacheService);
// 输出: "CacheService Created" (只输出一次，cache1 === cache2)
const handler1 = container.get(RequestHandler);
const handler2 = container.get(RequestHandler);
// 输出: "RequestHandler Created" (输出两次，handler1 !== handler2)
登录
