new Service() 是解耦的第一道坎，因其将调用方与具体实现硬编码绑定，导致替换、拦截或测试时需修改所有构造点；应通过工厂函数统一创建并注入实例，切断隐式耦合。
为什么 new Service() 是解耦的第一道坎
大型前端项目里，到处 new ApiClient()、new AuthManager()、new Logger()，看似简单，实则把调用方和具体实现死绑在一起。一旦要换 mock 实现、加拦截逻辑、或做单元测试，就得改所有构造调用点——这不是解耦，是硬编码。
依赖注入的核心动作不是“用框架”，而是“把实例的创建权交出去”。哪怕不用任何 DI 库，先统一收口到一个工厂函数里，就已经迈出关键一步：
const createServices = () => ({
api: new ApiClient({ baseUrl: import.meta.env.VITE_API_URL }),
auth: new AuthManager(localStorage),
logger: new ConsoleLogger(import.meta.env.DEV)
});
后续组件/模块只接收这些实例，不再自己 new。这一步成本极低，但能立刻切断 70% 的隐式耦合。
provide/inject 在 Vue 中的边界在哪
Vue 的 provide/inject 常被误当作“轻量 DI”，但它本质是祖先-后代传递机制，不解决生命周期管理、单例控制、或跨上下文复用问题。比如你在 setup() 里 provide('api', new ApiClient())，每次组件实例化都会新建一个 ApiClient，违背单例契约。
立即学习“前端免费学习笔记（深入）”；
真正安全的做法是：只 provide 已经由外部创建好的稳定实例（比如从工厂函数返回的对象），且明确标注哪些 key 是“服务契约”：
const services = createServices();
provide('services', services); // ✅ 提供整个服务对象
// 而不是 provide('api', new ApiClient()) ❌
使用时也别直接解构，保留引用一致性：
const { api } = inject('services'); // ✅ 复用同一实例
// const api = inject('api'); ❌ 语义模糊，易被误当成独立 token
注意：provide/inject 不支持 TypeScript 类型自动推导 service 结构，建议用 InjectionKey 显式声明类型，否则 IDE 补全和重构会失效。
TS + inversify 的最小可行接入路径
如果项目已用 TypeScript 且需要更严格的契约管理和多环境替换能力，inversify 是目前最轻量、侵入性最低的选择。它不接管组件生命周期，只管“谁提供什么实现”。
关键操作只有三步：
- 定义接口（不是类）作为契约：
interface ILogger { log(msg: string): void; } - 绑定实现（通常在应用入口）：
container.bind<ILogger>('ILogger').to(ConsoleLogger).inSingletonScope(); - 在需要处注入：
const logger = container.get<ILogger>('ILogger');
重点不是“怎么写装饰器”，而是避免两个坑：
第一，不要给每个 service 都写 @injectable()——只有被容器主动 get 的类才需要；普通工具函数、纯数据类、UI 组件一律不标。
第二，生产环境禁用 container.snapshot() 或动态重绑定，这些调试功能上线后必须删掉，否则会破坏 tree-shaking 和运行时稳定性。
React 中绕过 useContext 手动管理 DI 容器
React 没有原生 provide/inject，很多人一上来就封装 DIContext，结果把容器实例塞进 context，导致任意 consumer 更新都触发整棵子树重渲染。这不是解耦，是制造新的性能瓶颈。
更务实的做法是：把 DI 容器当普通模块变量导出，在具体 Hook 里按需取用：
// di/container.ts
export const container = new Container();
container.bind<ApiService>('ApiService').to(ApiService);
// hooks/useApi.ts
import { container } from '@/di/container';
export function useApi() {
return container.get<ApiService>('ApiService');
}
这样既保持依赖显式、可测试，又不引入 context 的渲染副作用。只要确保 container 初始化早于第一个 useApi() 调用（比如在 main.tsx 里初始化），就完全可控。
唯一要注意的是：别在组件顶层直接 container.get()，必须包在自定义 Hook 里——否则无法做依赖数组校验，也违背 React 的执行时机约束。
解耦真正的难点不在语法或工具，而在于识别哪些东西“必须抽象成契约”：不是所有类都需要接口，只有那些可能被替换、被 mock、或承担跨模块协作职责的才值得投入。过早抽象通用工具类，反而增加维护成本。
