考量到目前公司项目多，技术栈杂，体验不太友好，所以花了点时间大概研究了下微前端
大概分下面几个部分简单阐述下我的理解，算是自我小结吧：
- 微前端的简介
- 微前端的价值
- 微前端需要解决的问题
- 微前端的技术选型
- 微前端的实践总结
- 微前端存在的问题
1. 微前端的简介
微前端是一种类似于微服务的架构体系
它将微服务的理念应用于浏览器端，即将单页面前端应用由单一的单体应用转变为多个小型前端应用聚合为一的应用
各个前端应用还可以独立开发、独立部署
2. 微前端的价值
- 解耦：方便扩展，重构，替换，组合
- 旧项目里开发新模块
- 新项目怎么架构，在 3-5 年不会变成遗产项目
- 与业务组件有什么区别：技术无关
- 复用：能力输出
服务化
复用的层级
- 函数逻辑复用（模块化）
- 通用方法
- 业务方法
- 组件复用（组件化）
- 通用组件：antd，日期选择组件
- 业务组件
- 业务块复用（微前端）
通用业务块：财务，用户信息
- 服务化
编排服务、编排逻辑、编排组件、编排访问策略、编排流程
3. 微前端需要解决的问题
- 微应用的注册、异步加载和生命周期管理；
- 微应用之间、主从之间的消息机制；
- 微应用之间的安全隔离措施；
- 微应用的框架无关、版本无关；
- 微应用之间、主从之间的公共依赖的库、业务逻辑(utils)以及版本怎么管理；
- 微应用独立调试、和主应用联调的方式，快速定位报错（发射问题）；
- 微应用的发布流程；
- 微应用打包优化问题；
- 微应用专有云场景的出包方案；
- 渐进式升级：用微应用方案平滑重构老项目
4. 微前端的技术选型
服务端集成：如 SSR 拼装模板
构建时集成：如 Code Splitting
发布阶段耦合，不推荐使用
- 运行时集成：如通过 iframe、JS、Web Components 等方式
- iframe
- Web Components
- JS：比如前端路由
4.1 目前我们项目痛点
现状：MPA（多页面应用） + SPA（单页面应用）
痛点在于：
- 历史包袱重，人员更替频繁
- 项目多，技术栈杂、老旧
- 还存在大量 php 页面，未实现前后端分离
4.2 对我们公司的价值
4.2.1 优点
- 技术价值
- 使公司技术基础设施更开放，更容易引入优秀开源技术
- 提高团队技术水平
- 减少跨项目代码冲突问题
- 产品价值
- 跨产品共享模块
进一步优化产品交互体验
增加基座层，优化体验
全局loading
提取菜单，顶部，底部
提取公共库
预加载所有子项目文件
4.2.2 缺点
- 增加复杂度
- 增加流量成本
- 代码库数量增多，管理成本增加
- 开发环境复杂
5. 微前端的实践总结
5.1 qiankun
5.2 怎么解决微前端的问题
- 基座模式（主从应用）：就是在子应用之前加一层（基座层）
注册子应用，添加子应用生命周期（运行时集成） - 路由控制
通过唯一的子应用入口地址，获取要加载的资源（HTML Entry 方案）
- 样式隔离：切入插入样式，切出/卸载删除样式表，浏览器会自动刷新cssom
js 隔离：proxy/快照
预加载/按需加载
父子应用通信
5.3 实践中遇到的问题
- Entry 唯一：域名或端口不相同
- 开发环境允许跨域：disableHostCheck，headers
- package.json 中的 name 要唯一
- 静态资源应该是完整的资源地址
6. 微前端存在的问题
- 微前端拆分的粒度
- 微前端的源码怎么管理
- 微前端可以嵌套，要怎么拆分
- 提取菜单、顶部，子应用不独立了，怎么办
借用同事的一句话总结下：
没有银弹，只是多了一个权衡的维度