项目背景：

  1. app下架需要把所有页面都迁移到企业微信h5
  2. 规划架构：主应用提供菜单组件和公用方法，然后微应用需要渲染到指定的容器。所以要求微前端框架提供隔离样式的功能、以及通讯功能。

  3. 只给了一个月来接入主应用和子应用。子应用需要推动各部门来配合接入，月初提需求，月底上线第一批应用

    技术选型标准

  4. 基于时间紧迫，需要挑选可用，且接入成本低，社区活跃度高，遇到问题可以找到对应的解决方案的微前端框架

  5. 维度与评分

    • 成本
      • 接入成本（接入微前端框架要改动的东西）
      • 改造成本（基于这个微前端框架不支持的功能，需要自己实现的难度评估）
    • 收益
      • 微前端运行时功能完整性
      • 微前端工程化
      • 微前端运维
    • 风险
      • 社区活跃度（github star数量、已解决issue数量）
      • 可维护性（文档是否齐全、在技术社区是否可以找到对应的技术分享文章）
      • 可扩展性（随着越来越多的微应用接入，是否会导致管理上的不便）

        iframe

        iframe有天然的隔离性，但是隔离性太强，导致以下问题：

  6. 刷新后iframe的url状态丢失，无法控制iframe页面的前进后退；

  7. 想实现子应用免登录需要跨域共享cookie，反而导致安全性降低；
  8. 全局弹窗无法实现
  9. 企业微信h5的iframe不支持跨域请求页面，详见这里

因为 微前端运行时功能完整性 不能满足基本业务需求，直接放弃该方案。

single-spa

功能上：

  1. 兼容多框架
  2. html entry
  3. 加载和渲染原理：路由劫持，下载入口html，渲染到目标容器
  4. 不支持js隔离、样式隔离
  5. 不支持应用间通讯
  6. 不支持预加载
  7. 没有考虑微前端工程化和运维

成本：
接入成本：

  1. 子应用需要安装依赖，以及注册生命周期函数
  2. 主应用需要自己编写加载子应用的逻辑

改造成本：

  1. 需要自己实现js隔离、样式隔离
  2. 需要自己实现预加载
  3. 需要自己实现应用间通讯

风险：

  1. 社区活跃度 github star数量 11.3k、已解决issue数量 532（2022.6.27）
  2. 文档齐全，demo多

小结：

  1. 功能上，只做了路由劫持、提供参数填写加载微应用的逻辑。需要自己实现应用隔离、预加载和应用间通讯。微前端运行时功能完整性 低，得1分。没有考虑 微前端工程化 和 微前端运维 相关的功能。所以在收益这个维度，得分 1/9
  2. 成本上，接入需要自己手写加载微应用的逻辑，且子应用需要额外安装依赖，接入成本高，得1分。需要自己实现应用隔离、通讯、以及预加载等，改造成本高，得1分。所以在成本这个维度得分 2/6。

  3. 社区活跃度高，可维护性高；

    qiankun

    功能上：

  4. 基于single-spa完善以下功能：
    a. 应用隔离b. 支持预加载
    c. 基于props来实现父子通讯

    • js沙箱，根据Proxy的支持度以及是否多例，支持三种沙箱实现方式
    • 样式隔离：支持shadow dom方案，以及实验式样式隔离
    • 全局方法（setInterval、clearInterval、addEventListener、removeEventListener）劫持
  5. 没有考虑工程化问题：如公用依赖，组件复用
  6. 没有考虑到微前端平台运维

成本上：

  1. 接入成本：子应用需要接入生命周期代码；主应用需要接入注册微应用代码；
  2. 改造成本：需要自己考虑微前端工程化问题，以及微前端平台运维。

风险上：

  1. 社区活跃度：github star 数量 12.8k （统计时间20220622）

  2. 文档齐全，demo多

    emp

    功能上：

  3. 考虑了微前端的工程化问题，基于webapck5 MF功能解决公共依赖的问题，以及可以实现微组件共享。

  4. 不支持样式隔离和js隔离
  5. 它的设计是去中心化，每个子应用都可以再接入子应用，

成本上：
接入成本：

  1. 所有应用都要迁移到webpack5
  2. monorepo组织几个代码仓库

改造成本：

  1. 基于webpack5 MF实现公共依赖和组件共享，需要另外做基建来统一引入这些包的入口。还有公建文档的问题。
  2. 微组件共享是基于vuera这个库来实现的，只支持vue和react的组建共享
  3. 需要自己实现应用隔离

风险上：

  1. 社区活跃度：社区活跃度不高 star 1.8k （统计时间20220622）
  2. 文档不完善

小结：
emp比较适合大型且处于立项初期时选用。需要事前做monorepo的规划、样式统一规划。

microapp

功能上：

  1. 抛弃了路由劫持的思路，选用类web component的方案
  2. 基于CustomElement和样式隔离、js隔离来实现微应用的加载，所以子应用无需改动就可以接入
  3. 支持应用隔离
  4. 通过劫持底层接口实现了元素隔离
  5. 提供了插件系统
  6. 支持预加载
  7. 没有考虑工程化问题：如公用依赖，组件复用
  8. 没有考虑到微前端平台运维

成本：
接入成本：子应用无需改动，主应用需要接入微应用代码
改造成本：需要自己考虑微前端工程化问题，以及微前端平台运维。
风险：

  1. 这个框架基于CustomElement和Proxy API，前者针对低版本有polyfill，但后者没有，且目前官方文档说没有做兼容的计划
  2. 社区活跃度 star 2.7k（统计时间20220622）
  3. 文档齐全

    总结

    iframe、single-spa 在功能完善度上不足，所以放弃选择；
    emp 比较适合在项目初期选型使用，用约定来规避样式隔离和js隔离（所以 emp 没有把应用隔离考虑进去），比较适合在大型项目中使用；
    microapp 和qiankun，功能完整度上比较好，尽管 microapp 比 qiankun 多了元素隔离功能、插件系统，且使用了类web component的思路降低子应用的接入成本。但基于 microapp 对 Proxy目前不考虑兼容，且社区活跃度上，qiankun 更胜一筹，工期短需要有一定的保障，所以最后选了qiankun

    参考资料：

    https://github.com/micro-zoe/…
    https://github.com/efoxTeam/e…
    https://juejin.cn/post/684668…
    https://github.com/efoxTeam/e…