单例工厂模式重构前端插件架构

本文深入剖析了前端插件体系中“单例工厂”这一关键实践——它并非新设计模式，而是将单例生命周期管理与工厂函数逻辑巧妙融合的工程方案：主应用在启动时统一调用工厂、注入已初始化的单例服务对象，从而彻底规避插件内直接 new 实例引发的状态混乱、环境强耦合与测试脆弱等顽疾；通过明确约定工厂调用时机、返回纯对象、拆分真实/模拟实现，并强制插件通过上下文安全消费服务，真正实现了构建时可配置、运行时可替换、类型安全且易于测试的插件依赖体系——让你一套代码适配多环境，无需修改插件源码，更不用在几十个文件里手动替换构造调用。

直接说结论：所谓“单例工厂”在前端插件体系里不是一种独立模式，而是单例生命周期管理和工厂函数创建逻辑的组合实践；它能实现运行时动态注入，但前提是插件不自行 new 实例、不硬编码环境判断、且所有服务入口统一收口。

为什么不能在插件里直接 new Service()？

插件代码若写 new ApiClient() 或 new Logger()，等于把实现细节和当前环境（开发/测试/生产/Mock）强绑定。一旦要切换 mock 环境，就得打开每个插件文件去改构造调用——这不是动态注入，是批量字符串替换。

• 每次 new 都产生新实例，破坏单例契约，导致状态不一致（比如 auth token 重复初始化）
• 无法在运行时拦截或装饰实例（如加请求日志、自动重试、token 刷新）
• 单元测试时无法传入 mock 实现，只能靠 jest.mock() 全局打补丁，脆弱且难维护

单例工厂函数怎么写才真正可控？

关键不是“工厂”，而是“谁调用工厂”和“工厂返回什么”。必须由主应用在启动阶段一次性调用，并将结果作为稳定对象注入插件上下文，而不是让插件自己调用工厂。

• 工厂函数应接收明确的环境参数，例如 createServices({ env: import.meta.env.MODE, isMock: import.meta.env.VITE_ENABLE_MOCK })
• 返回值必须是普通对象（非 class 实例），且所有字段都指向已创建好的单例：{ api: new ApiClient(...), logger: new ConsoleLogger(...) }
• 禁止在工厂内部做条件 if (isMock) return new MockApiClient() —— 这会让类型不可靠；应拆成两个独立工厂：createRealApiClient() 和 createMockApiClient()，由上层决定调用哪个

示例：

export const createServices = ({ env, isMock }: { env: string; isMock: boolean }) => {
  const api = isMock 
    ? createMockApiClient() 
    : createRealApiClient({ baseUrl: import.meta.env.VITE_API_URL });

  return {
    api,
    logger: new ConsoleLogger(env === 'development'),
    storage: new LocalStorageAdapter(),
  };
};

插件如何安全消费这些服务？

插件不能依赖全局变量或 import 某个 service 文件，而必须通过显式传入或从统一上下文获取。Vue 插件可利用 app.config.globalProperties，React 插件应走 Context 或 props 注入，纯 JS 插件则靠初始化时传入 services 对象。

• Vue 中避免 provide('api', new ApiClient()) —— 这会在每次组件 setup 时新建实例
• 正确做法是 provide('services', services)，然后插件里用 inject('services') 取整个对象
• TypeScript 下必须用 InjectionKey 声明类型，否则 inject 返回 any，IDE 补全失效、重构易出错
• 插件内部不要解构服务：const { api } = services ✅；不要写 const api = inject('api') ❌（语义模糊，且破坏引用一致性）

运行时切换依赖的边界在哪？

真正的“运行时切换”只发生在主应用重启或插件热重载时，不是指用户点个按钮就让已挂载的 ApiClient 实例突然变成 mock 版本——那需要代理或拦截器支持，属于另一层设计。当前方案能保证的是：同一份插件代码，在不同构建产物中加载不同的服务实现，且无需修改插件源码。

最容易被忽略的一点：所有插件的初始化时机必须晚于 createServices() 执行完成，否则拿到的是空或未定义的服务引用。常见坑是插件在 definePlugin 阶段就尝试访问 services.api，但此时主应用还没调用工厂函数。

本篇关于《单例工厂模式重构前端插件架构》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！