前言
目前接触的项目都是较大型的项目，业务体量较大，内容功能也比较多，做一下微前端的一些技术心得便于后期回顾
微前端的概念
前端社区最早在14年左右就开始探索相关的概念（如Spotify的模型）
2016年11月 ThoughtWorks 的技术团队发布了关于微前端的文章，在其中正式提出了微前端的术语以及其系统化的定义。直接映射后端架构中的微服务概念
微服务
后端架构：微服务（Microservices）
这是微前端最核心的灵魂。它几乎全盘照搬了微服务的组织原则和工程价值观：
康威定律（Conway's Law）
原理
设计系统的组织，其产生的设计和架构等价于组织间的沟通结构。
微前端应用
如果公司有订单团队、用户团队、支付团队，那么前端架构也应该拆分为订单微应用、用户微应用、支付微应用。让团队拥有端到端的交付能力，而不是让所有前端都维护一个巨大的仓库。
去中心化治理（Decentralized Governance）
借鉴点
后端微服务允许不同服务使用 Java、Go、Node.js 等不同语言。
应用
微前端应用：允许子应用 A 用 Vue2，子应用 B 用 React 18，子应用 C 用 Angular。技术栈选型权下放给子团队。
独立部署与扩展
借鉴点
修改支付服务不需要重启订单服务。
微前端应用
发布购物车功能时，只需重新构建和部署购物车子应用，主框架和其他子应用无感知，无需全量回归测试。
浏览器原生标准：Web Components & iframe
为了解决如何在同一页面运行多个应用且不冲突的技术难题，微前端深度借鉴了浏览器的原生隔离机制
iframe 的隔离思想
借鉴点
iframe 是浏览器提供的天然沙箱，JS、CSS、DOM 完全隔离。
微前端应用
早期的微前端方案（以及现在的 wujie/无界、Single-SPA 的 iframe 模式）直接利用 iframe 作为运行容器。即使是 qiankun 这种基于 JS 沙箱的方案，其设计目标也是**“模拟 iframe 的隔离性，但去除 iframe 的缺点（如通信难、URL 不同步、性能开销大）。
Web Components(Custom Elements & Shadow DOM)：
借鉴点
W3C 标准允许开发者创建自定义 HTML 标签，并利用 Shadow DOM 实现样式封装。
微前端应用
现代微前端框架（如 wujie、Micro-App、Qiankun 3.0 探索方向）大量使用 Web Components 技术。基座应用将子应用包裹在一个自定义标签（如 <micro-app name="cart">）中，利用 Shadow DOM 或类似的插槽机制（Slot）来实现样式的天然隔离和内容的投影。
架构图
微前端的四种经典组合模式
| 模式 | 核心思路 | 借鉴来源 | 典型场景 |
|---|---|---|---|
| 1. 路由分发式 | 不同 URL 路径指向不同的独立应用（Nginx 反向代理）。 | 传统 MPA (多页应用) | 简单的后台管理系统，模块间跳转允许刷新页面。 |
| 2. 前端微服务化 | 在 JS 运行时动态加载子应用，共享页面容器。 | 微服务 + JS 沙箱 (qiankun, single-spa) | 需要无缝体验的 SaaS 平台，技术栈混合。 |
| 3. 服务端组合 | 在 HTML 生成阶段拼接碎片。 | SSI / ESI | 对 SEO 要求高、首屏性能极敏感的 C 端页面（如电商首页）。 |
| 4. 边缘组合 (Edge) | 在 CDN 边缘节点进行 HTML 流式组装。 | Cloudflare Workers / Lambda@Edge | 全球分布的大型应用，追求极致低延迟。 |
设计哲学
契约优先
- 思路：微前端之间不能随意耦合。基座与子应用、子应用与子应用之间，必须定义清晰的通信契约（如自定义事件名称、Global State 结构、URL 参数规范）。
- 借鉴：类似于微服务间的 API 接口定义（Swagger/OpenAPI）。
- 实践：严禁子应用直接操作 window 全局变量（除非通过沙箱），严禁子应用直接查询其他子应用的 DOM 节点。
渐进式演进
- 思路：不要试图一次性重构整个巨石应用。
- 借鉴：后端重构中的 “绞杀者模式（Strangler Fig Pattern）。
- 实践：在新项目中，先搭建微前端基座。老功能暂时保持原样（或作为一个子应用接入），新功能用新技术栈开发为新的微应用。随着时间推移，逐步将老功能剥离、重写、替换，直到老系统完全消失。
自治与治理的平衡
- 思路：给予团队最大的自由度，但保留必要的底线。
- 借鉴：联邦制政治结构。
- 实践： 自治：子应用选什么 UI 库、怎么组织代码、什么时候发布，团队自己定。 治理：基座统一处理登录鉴权、统一埋点规范、统一错误监控上报、统一设计语言（Design Token）。
容错设计
- 思路：单个子应用的崩溃不应导致整个页面白屏。
- 借鉴：后端服务的熔断降级机制。
- 实践：基座应用需要具备“异常捕获”能力。如果“评论模块”加载失败或报错，基座应能捕获错误，仅在该区域显示“加载失败”的占位图，而保证“商品详情”和“购买按钮”依然可用。
场景
场景一
随着业务的不断发展，Saas系统变得越来越大，每次启动项目，打包都需要大量的时间。如果进行按业务拆分，可以做到单包体积缩小，减少启动时间与打包时间
场景二
公司中不同的业务系统越来越多，有cms、erp等内容，需要进行融合，有价值的业务融合，老旧项目融合等场景
