单例工厂重构插件体系，实现动态依赖注入

本文深入剖析了前端插件体系中依赖注入的核心痛点，指出直接使用 `new Service()` 构造插件会导致环境判断固化、实例不可复用、测试困难、依赖顺序敏感等顽疾；主张以纯函数形式的“单例工厂”（如 `createPlugins(config)`）统一管控插件实例的创建逻辑，实现真正可运行时切换、可测试、可复用的动态依赖注入，并详解了如何结合 Vue 的 `provide/inject` 或 React 的 `Context` 安全接入，强调工厂调用时机可控、全局依赖参数化注入等关键实践，为构建高内聚、低耦合、面向演进的插件架构提供了清晰可行的技术路径。

直接用 new Service() 创建插件依赖，就别谈“运行时动态注入”了——实例在构造时已固化，环境判断逻辑被锁死在调用点里，根本没法切。

为什么插件体系必须放弃 new Service() 构造

前端插件（比如编辑器扩展、图表渲染器、权限校验器）一旦在模块顶层或组件 setup 中写 new AuthPlugin() 或 new ApiAdapter()，等于把环境判定（dev/staging/prod/mock）和实例生命周期一起焊死。后续想按用户角色加载不同实现、或测试时替换为 stub，就得改源码、清缓存、重打包。

• 每次 new 都是新实例，无法复用连接、缓存、状态
• 环境判断逻辑分散在各插件内部，无法统一收口控制
• 插件间若互相依赖（如 LoggerPlugin 依赖 ConfigPlugin），new 顺序错乱会导致 undefined 行为

用工厂函数封装插件创建逻辑

把所有插件的实例化过程收归一个纯函数，输入环境标识或配置对象，输出稳定的服务实例集合。这才是“单例工厂”的实质：不是全局单例，而是“一次决策、多次复用”。

• 工厂函数必须是纯的（无副作用），只做实例创建，不触发副作用（如初始化网络请求）
• 参数应包含可运行时变更的字段，例如 { env: import.meta.env.MODE, tenantId: 'abc' }
• 返回值建议用对象字面量，避免导出 class 实例导致 TS 类型推导断裂

示例：

export const createPlugins = (config: { env: string; tenantId: string }) => ({
  auth: config.env === 'mock'
    ? new MockAuthPlugin({ tenantId: config.tenantId })
    : new RealAuthPlugin({ baseUrl: '/auth', tenantId: config.tenantId }),
  logger: new ConsoleLogger({ enabled: config.env !== 'production' }),
  storage: config.env === 'test'
    ? new MemoryStorage()
    : new LocalStorageAdapter()
});

插件如何安全接入 Vue provide/inject 或 React Context

provide/inject 不是 DI 容器，它只是传递机制。你 provide('plugins', createPlugins(...)) 是安全的；但 provide('auth', new AuthPlugin()) 是危险的——后者每次组件实例化都会重新执行 new，破坏单例语义，且无法响应环境变化。

• Vue 中：只 provide 工厂返回的对象，不要 provide 单个插件实例
• React 中：用 useContext 消费整个 plugins 对象，而非解构后单独 useContext(AuthContext)
• TypeScript 下必须用 InjectionKey（Vue）或泛型 Context（React），否则 IDE 无法识别属性类型

环境切换必须发生在插件工厂调用之前

真正能“运行时切换”的前提是：插件工厂函数的调用时机可控。常见错误是把它写死在 main.ts 入口，导致构建时就固化了 env 值。正确做法是延迟到首次需要插件时才调用，比如在登录成功后、或路由守卫解析完用户 profile 后。

• 不要在 createApp() 前调用工厂函数
• 推荐在根组件 setup() 或自定义 Hook 中首次调用，并缓存结果（用 ref 或 useState）
• 若需热切换（如管理员后台手动切 mock），工厂函数需支持传入新 config 并返回新插件对象，旧实例应主动 .destroy() 或交由 GC 回收

最易被忽略的一点：插件自身是否持有对 window、localStorage、fetch 的直接引用。这些全局依赖必须也通过参数注入，否则工厂切换再彻底，底层行为仍不可控。

今天关于《单例工厂重构插件体系，实现动态依赖注入》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！