微前端 概念详解 什么是微前端？ 微前端（Micro-Frontend），是将微服务（Micro-Services）理念应用于前端技术后的 相关实践，使得一个前端项目能够经由多个团队独立开发以及独立部署。
01 微前端开发的特性 技术无关：各个开发团队都可以自行选择技术栈，不受同一项目中其它团队影 技术无关 响； 代码独立：各个交付产物都可以被独立使用，避免和其它交付产物耦合； 样式隔离：各个交付产物中的样式不会污染到其它组件； 原生支持：各个交付产物都可以⾃由使⽤浏览器原⽣ API，⽽⾮要求使⽤封装后的 API； 解决了什么问题？ 解决应⽤越来越⼤，维护成本⾼的问题
主要体现在：
代码复杂度不可控，多⼈协作带来困难 模块容易相互影响，⼀个模块出错，往往导致另外模块出错 项⽬扩展性差，不利于横向扩展 ⽆法独⽴部署，为什么需要独⽴部署 技术选型灵活，真的必要吗？ 02 微服务平台和微前端对⽐
- 微服务 微前端 备注 服务 独⽴服务，⽐如交易服务 应⽤或者模块，⽐如导航 服务是不会相互影响的 服务治理 服务注册/发现/依赖管理/跟踪/降级/限流/⽇志/ 应⽤的发现/路由/监控/降级/运⾏/注销/聚合 等 需要⼀个/多个系统统⼀处理⼀些上层的事情 服务通信 HTTP / RPC/ 中间件 eventBus/ sharedWorker/ LocalStorage 03 微前端基本构成 中心化路由，服务注册中心 标识化应用 设计一定的生命周期 部署和配置自动化 部署更新 title:常见的微前端结构 应用信息 主程序 js/css/assets/common Router.EventBus.LifeCycle 应用1js/css/assets 应用2js/css/assets 应用场景 常见场景 是将单个应⽤拆分为多个独⽴的应⽤，通过导航栏和动态加载来实现⽆缝的切换 单个⻚⾯上的模块也可以拆分为不同的微前端 如何实施微前端 **拆分和聚合 **
常⻅的⽅式 ⼤仓库通过 monorepo methodology 做成npm包，集成主项⽬ 拆分多仓库，动态加载的⽅式进⾏集成
常见技术实现方案 通过IFrame⽅式进⾏聚合 使⽤WebComponent构建应⽤ 在不同的框架之上设计通讯、加载机制，诸如 Single-SPA iframe现存问题 不可控制：iframe嵌⼊的显示区⼤⼩不容易控制，存在⼀定 局限性
bfcache！ URL的记录完全⽆效，⻚⾯刷新不能够被记忆， 刷新会返回⾸⻚，iframe功能之间跳转也⽆效。
兼容性坑 iframe的样式显示、兼容性等都具有局限性
性能开销 frame 阻塞 onload、占⽤连接池、多层嵌套⻚ ⾯崩溃。。
iframe方案实现方式 通过菜单聚合，含有两个应⽤ Vue/React 刷新需要保持状态
对于⼀些共⽤ UI 组件⽽⾔，仍然需要重复加载。这也就是 iframe 模式下的问题
Iframe嵌套是⼀个⽐较⼤的问题
Iframe在移动端适配的时候存在⼀些兼容性问题
Iframe的优势也⽐较明显
改造成本低，可以快速上线
沙盒模型，各个模块天然隔离，不需要考虑样式污染，应⽤之间的相互影响 1 2 3 4 5 6 7 8 9 10 11 WebComponents 场景：单⻚⾯应⽤，业务⽐较复杂，需要解耦
开发效果 ⽅案： 分为三个模块，专⼈维护 ⻚⾯相同的技术栈和规范，构建相同 开发示意图
SIngle-SPA 业务越来越复杂了， 有些应⽤要其他技术栈
SIngle-SPA-Portal 技术栈多样
代码太⼤，需要拆库
需要独⽴部署，减少影响
难点： 公共库如何管理，如何解决CSS冲突的问题
