JavaScript 中的依赖注入是通过参数传递实现的解耦策略，非语言原生特性；它提升可测试性，因依赖可被 mock 替换，使单元测试隔离外部副作用，推荐从手动注入和接口契约开始。
JavaScript 中的依赖注入（Dependency Injection, DI）本身不是语言原生特性，而是通过设计模式和工具实现的一种解耦策略。它不靠框架强制注入，而是把外部依赖“传进来”，而不是在内部自己创建或查找。这种方式让模块更专注自身逻辑，也更容易替换依赖（比如用模拟对象替代真实 API），从而显著提升可测试性。
依赖注入的核心：把依赖作为参数传入
最直接的方式是函数参数或构造函数参数接收依赖：
- 不推荐：模块内部直接 new 一个服务实例，或调用全局单例（如 new ApiClient()）
- 推荐：把服务实例当作参数传给函数或类，由调用方决定传什么
例如：
class UserService {
constructor(apiClient) {
this.api = apiClient; // 依赖被注入，而非内部创建
}
fetchUser(id) {
return this.api.get(`/users/${id}`);
}
}
// 测试时可以轻松传入 mock 实例
const mockApi = { get: jest.fn().mockResolvedValue({ id: 1, name: 'Alice' }) };
const service = new UserService(mockApi);
await service.fetchUser(1);
expect(mockApi.get).toHaveBeenCalledWith('/users/1');
手动注入 vs 容器管理
小项目中，手动传递依赖足够清晰；大项目可能借助轻量容器（如 InversifyJS、Awilix）或构建时工具（如 TypeScript + Decorators 配合 DI 容器）自动解析依赖树。
立即学习“Java免费学习笔记（深入）”；
- 手动注入：控制明确、无额外抽象，适合多数前端应用
- 容器注入：适合复杂层级、需生命周期管理（如单例、瞬态）的后端 Node.js 服务
- 注意：浏览器环境没有“启动容器”的概念，所谓“DI 容器”本质仍是提前注册 + 运行时解析，不能像 Java Spring 那样全自动代理
为什么能提高可测试性
关键在于“隔离”。单元测试应只验证目标模块行为，不触发真实网络、数据库或第三方 SDK。
- 依赖被注入 → 可用 mock/stub/fake 替换 → 测试不依赖外部状态
- 模块不再隐藏副作用（如悄悄发请求）→ 行为可预测、断言更可靠
- 接口契约清晰（比如只依赖 ApiClient 的 get 方法）→ 只需满足该接口，实现可自由切换
实际建议：从简单开始，避免过早抽象
不必一上来就引入 DI 容器。先养成“依赖外传”的习惯：
- 函数尽量接收依赖作为参数，而不是闭包引用或全局变量
- 类的构造函数显式声明所需服务，避免在方法里 new 或 import 具体实现
- 使用 TypeScript 接口定义依赖契约（如 interface HttpClient { get(url: string): Promise
; } ），增强类型安全和可替换性 - 测试文件中直接构造 mock 对象，比依赖容器更轻量、更易调试
