SPA工程中依赖注入实现逻辑与UI解耦方法

在大型SPA开发中，真正的依赖解耦远不止于引入DI库或使用provide/inject，关键在于彻底剥离“谁创建、何时销毁”这一职责——避免直接new Service()带来的测试困难、内存泄漏、单例失效和框架绑定问题；必须通过工厂函数统一管理实例生命周期，配合InjectionKey保障TypeScript类型安全，并以接口而非具体类定义依赖契约，才能实现跨框架复用、可测试、易维护的真正解耦架构。

直接用 new Service() 创建依赖，业务逻辑就和 UI 框架生命周期绑死了；真解耦不是换 DI 库，而是把“谁创建、何时销毁”从组件里彻底移出去。

为什么 new Service() 是解耦的第一道坎

大型 SPA 里满屏 new ApiClient()、new AuthManager()、new Logger()，看着干净，实则每个 new 都在组件内部埋下耦合炸弹：

• 测试时无法替换为 mock 实例，只能 patch 全局构造函数或改源码
• 要加请求拦截、日志上下文、重试策略？得改所有 new 点，漏一个就出问题
• 组件卸载后实例还挂着（比如未取消的定时器、事件监听），引发内存泄漏
• Vue/React 组件重渲染不等于服务该重建——但 new 每次都新建，违背单例语义

provide/inject 不是 DI，只是传递通道

Vue 的 provide/inject 常被误当 DI 工具，但它不管理实例生命周期，也不保证单例。常见错误写法：

• provide('api', new ApiClient()) → 每次 setup 都新建，不同组件拿到的是不同实例
• const api = inject('api') → key 名模糊，类型丢失，TS 推导失效，重构时 rename 会静默失败

安全用法只有一条：先用工厂函数统一创建，再 provide 整个服务对象：

const services = createServices(); // 工厂返回稳定实例
provide('services', services); // ✅ 提供对象，非单个实例

消费端也必须解构自同一对象，确保引用一致：

const { api, logger } = inject('services'); // ✅ 同一引用

必须用 InjectionKey 守住 TS 类型底线

不用 InjectionKey，Vue 的 inject 返回 any，IDE 补全失效，TS 编译器不校验字段名拼写。正确姿势：

import { InjectionKey } from 'vue';
export const ApiKey: InjectionKey = Symbol('ApiClient');

提供时用 key 注册：

provide(ApiKey, services.api); // ✅ 类型受控

消费时用 key 获取，自动获得类型推导：

const api = inject(ApiKey); // ✅ api 类型为 ApiClient，字段补全可用

这一步不做，后续所有“解耦”都是裸奔——类型系统形同虚设，重构风险陡增。

跨框架复用的前提：依赖契约必须是接口，不是类

想让同一套业务逻辑跑在 Vue、React 甚至 SSR 环境，依赖不能绑定具体实现类。例如：

• ❌ 错误：class ConsoleLogger → React 里没法直接用
• ✅ 正确：定义 interface ILoggable，所有服务实现该接口，业务逻辑只依赖 ILoggable

工厂函数返回的实例，也必须基于接口构造，而非具体类名。否则，哪怕用了 inversify 或 provide/inject，只要契约是 class，跨环境替换就必然要改业务代码。

到这里，我们也就讲完了《SPA工程中依赖注入实现逻辑与UI解耦方法》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！