微前端是一种多个团队通过独立发布功能的方式来共同构建现代化 web 应用的技术手段及方法策略。

特点

  • 与技术栈无关
  • 应用之间不应该有任何直接或间接的技术栈、依赖、以及实现上的耦合

    与技术栈无关

    诉求是为了解决项目变老后难以进行迁移的问题。微前端首先解决的，是如何解构巨石应用

    在主系统构造一个足够轻量的基座，然后让各子应用按照共同的协议去实现即可。这个协议可以包括，主应用应该如何加载子应用，以及子应用如何被主应用感知、调度，应用之间如何通信等。这个协议不应该包括，子应用要如何确保隔离性、安全性，也就是子应用除了实现一些较为简单的协议之外，跟开发一个正常的 spa 应用应该没有任何差别，包括不应该有 开发、构建、发布 等流程上的侵入。只要子应用实现了这几个协议，其他的东西怎么玩，我们都不需要关心或干预。

应用之间不应该有任何直接或间接的技术栈、依赖、以及实现上的耦合

不能要求子应用、主应用必须使用某一版本的技术栈实现。
尽量基于浏览器原生的 CustomEvent api，而不是自己搞的 pub/sub。
子应用是否具备不依赖宿主环境独立运行的能力，衡量标准是是否能一行代码不改，或者只改很少的配置，就能达成这一目标。
方案上跟使用 iframe 做微前端一样简单，同时又解决了 iframe 带来的各种体验上的问题。（以前很多项目都是导航栏、内容区等通过iframe进行引入不同项目，独立维护，互相之间通过postMessage通信交互…）。

  • url 不同步。浏览器刷新 iframe url 状态丢失、后退前进按钮无法使用。
  • UI 不同步，DOM 结构不共享。想象一下屏幕右下角 1/4 的 iframe 里来一个带遮罩层的弹框，同时我们要求这个弹框要浏览器居中显示，还要浏览器 resize 时自动居中..
  • 全局上下文完全隔离，内存变量不共享。iframe 内外系统的通信、数据同步等需求，主应用的 cookie 要透传到根域名都不同的子应用中实现免登效果。
  • 慢。每次子应用进入都是一次浏览器上下文重建、资源重新加载的过程。

具备流通能力的，且这个流通能力不会因为主应用的实现升级而丧失（也就是说在 19 年能接入主应用的微前端应用，到了 2025 年也应该能正常接入正常运行，并同样保有在不同主应用间流通的能力）。