qiankun 能解决什么，不能解决什么

在大型前端项目里，qiankun 经常被当成拆分系统的方案。不过它解决的主要是多个应用如何在浏览器里组合运行，而不是拆分之后的所有工程问题。

它能解决的问题

qiankun 提供了子应用注册、加载、挂载和卸载的机制，主应用可以根据路由切换不同的子应用。各个子应用也可以使用不同的技术栈，并保留独立开发和部署的空间。

它还提供 JavaScript 沙箱、样式隔离和预加载等能力，用来减少全局变量、样式和资源加载带来的冲突。对于需要逐步整合多个旧系统，或者多个团队有不同发布节奏的项目，这些能力可以降低应用接入的成本。

它不能解决的问题

qiankun 不会自动划分合理的业务边界。如果子应用之间频繁共享状态、互相调用内部逻辑，拆分后只是把代码耦合变成了运行时耦合，维护成本可能更高。

它也不能替团队统一接口协议、登录状态、依赖版本、设计规范和监控体系。这些仍然需要明确的工程约定。沙箱和样式隔离主要用于减少冲突，也不是浏览器级的安全边界，不能用来安全运行不可信代码。

微前端同样不会天然提升性能。页面可能需要加载更多运行时代码和子应用资源，预加载只能改善部分体验，不能消除资源体积和初始化成本。

工作中怎么判断

以下场景比较适合使用 qiankun：

• 公司已有多个独立系统，希望接入同一个门户，同时暂时不能重写
• 不同团队负责相对独立的业务，需要各自开发、测试和发布
• 旧系统需要逐步迁移，新旧技术栈要在一段时间内同时运行
• 系统边界已经比较清楚，子应用之间只需要少量、稳定的通信

以下场景通常不适合使用：

• 一个团队维护中小型应用，只是代码量变大或目录混乱
• 业务边界还不清楚，子应用之间需要频繁共享状态和调用逻辑
• 只是想升级框架或提升性能，这些问题不会因为引入微前端自动消失
• 需要运行不可信代码，或者要求严格的安全隔离
• 团队还没有统一登录、部署、监控和异常处理，却希望 qiankun 顺便解决这些问题

简单来说，qiankun 更适合解决多个应用如何组合，而不是单个应用如何写好。只有独立开发和发布带来的收益大于额外的协作成本时，才值得引入。