Garfish、qiankun 和 single-spa 该怎么选？

Garfish、qiankun 和 single-spa 都能做微前端，但它们解决问题的层级不同。single-spa 更像底座，只管应用注册、激活和生命周期；qiankun 在它之上补齐沙箱、资源加载和工程实践；Garfish 也提供开箱能力，同时更强调运行时加载、插件化和相对轻量的接入体验。选型时别只看“谁更先进”，要看团队是否需要高度定制、是否已有历史应用、是否能承担框架生态和运维成本。

三者核心差异是什么？

如果团队刚开始做微前端，single-spa 的自由度最高，但很多事情要自己补，比如资源加载、样式隔离、全局变量污染处理和错误兜底。qiankun 的优势是成熟，资料多，历史项目验证多，适合需要稳定社区经验的团队。Garfish 的优势在于配置更直接，插件机制和应用调度能力比较顺手，适合希望快速把多个独立应用纳入同一门户的场景。取舍也很明显：生态越成熟，约束和历史包袱越多；框架越轻，团队自己补规范的责任越大。

维度	Garfish	qiankun	single-spa
定位	开箱式微前端框架	成熟微前端方案	生命周期底座
接入成本	中低	中	高
自定义空间	较高	中	最高
沙箱与隔离	内置能力较完整	方案成熟	需自行实现
社区资料	中等	较多	国际化资料多

Garfish 的优势在哪里？

Garfish 对主应用注册、子应用加载、生命周期和沙箱做了较完整封装，配置量比裸用 single-spa 少。对于已有多个 React、Vue 或普通 SPA 的团队，它能让子应用在较少改造下接入。另一个优势是运行时灵活性，入口可以按环境、租户、版本动态切换，这对灰度发布有帮助。边界是框架不能替你解决组织问题，如果应用间契约、样式规范和发布流程没定好，换任何框架都会乱。

ts
Garfish.run({
  apps: [{
    name: 'crm',
    entry: window.__entries__.crm,
    activeWhen: '/crm',
    props: { tenantId: getTenantId() },
  }],
  plugins: [monitorPlugin(), authFallbackPlugin()],
});

什么时候不适合选 Garfish？

如果团队已经深度使用 qiankun，且现有沙箱、构建、监控和发布链路都稳定，迁移到 Garfish 未必划算。迁移收益必须覆盖测试、适配和培训成本。另一个边界是如果你只是想共享几个组件或工具函数，Module Federation 或普通 npm 包可能更合适，没必要上完整微前端。常见踩坑是把微前端当成性能优化手段，结果增加了运行时加载和治理成本。

追问

Garfish 和 qiankun 最大的选择差异是什么？

差异不只是 API，而是生态成熟度和团队治理方式。qiankun 的资料、案例和踩坑经验更多，Garfish 的接入体验和扩展方式更轻。取舍是前者更稳妥，后者在新项目里更容易按自己的平台规则搭起来。边界是如果公司已有 qiankun 基建，除非有明确痛点，否则不要为了换框架而换框架。

single-spa 为什么还值得了解？

single-spa 是很多微前端方案背后的生命周期模型，理解它能帮助你判断框架到底替你做了什么。直接使用它适合架构团队很强、需要完全定制加载和隔离策略的项目。取舍是自由度换来了工程成本，业务团队可能会被大量底层细节拖住。踩坑点是只接了生命周期，却忘了资源隔离和错误恢复，线上问题会很难定位。

Module Federation 能替代 Garfish 吗？

它们关注点不同。Module Federation 更适合模块级共享，比如多个应用共用组件、工具库或业务模块；Garfish 更适合应用级集成，比如把多个独立 SPA 放到同一个门户下。取舍是 Federation 对构建体系要求更高，Garfish 的运行时边界更清楚。边界是两者可以组合使用，但要管好依赖版本，否则共享依赖会变成隐形耦合。

老项目迁移到 Garfish 应该怎么做？

不要一次性全迁，先挑一个边界清晰、依赖少、访问量可控的子应用试点。迁移时先保证独立运行，再接入主应用，最后补监控和灰度。取舍是分阶段会拉长周期，但能把风险压住。常见坑是只改入口和生命周期，不处理全局样式、定时器和跨应用跳转，结果测试环境正常、生产环境互相污染。

面试或评审里怎么回答选型问题？

先讲业务约束，再讲框架能力，不要直接说某个框架更好。比如团队是否多技术栈、是否要独立发布、是否已有基建、是否要求强隔离。边界是微前端不是默认答案，小团队单体 SPA 可能更简单。能说清这些取舍，比背一张对比表更有说服力。