起源
微前端改变由ThoughtWorks在2016年提出,借鉴了微服务架构理念,核心在于将一个庞大的应用拆迁成多个子应用,子应用可独立开发，独立部署
横向对比
iframe方案
- 优点:接入简单
- 缺点：应用间通信麻烦,要用postmessage或其他方式实现
iframe滚动条样式问题
刷新页面，状态url失效,前进后退按钮无效
nginx路由分发
- 优点:通过nginx反向代理接入子应用,部署简单
- 缺点：子应用间通信繁琐
微前端
- 优点：子应用可以独立开发,独立部署,与技术栈无关
- 缺点：得按搭建的微前端脚手架解决路由,父子通信,样式这些问题,框架上手成本
Webpack4模块联邦
内部几种微前端实现方案对比
wujie(腾讯)
qiankun(蚂蚁)
架构图
qianku区别于single-spa主要两点是HTML-entry和sandbox(沙箱),qiankun沙箱是用proxy代理实现的。
micro-app(京东)
single-app
使用qiankun具体会碰到的问题点
主应用和子应用技术栈复杂
主应用 umi3+qiankun
子应用
react 分为生命周期版本和hooks版本 ，除了自研脚手架,搭建的构建工具又会有webpack4,webpack5，vite,还会有umi(umi3与umi4写法和插件又会有区别), create-react-app,next之类的成熟脚手架,Vue版本有vue2,vue3
父子应用 子应用间通信问题
子应用嵌套问题 假如子应用下嵌套其他子应用
父子路由问题 假设父应用是history 子应用是history
权限设计以及token设计
qiankun对vite的兼容
开发环境,构建环境区别
共同依赖是否需要提取 比如公共组件
微前端使用场景
适合于B端一些后台管理系统的整合,使不同技术栈构成的模块间形成闭环，各个系统模块子应用又可以独立开发,独立部署,比较适合承接一些上线稳定技术栈老的应用的同时新模块用新技术栈开发。
但是话说回来,虽然微前端和技术栈无关,但是尽量统一主应用,子应用使用的技术栈可以一定程度上解决很多问题,技术栈不宜过度发散。
