Micro Frontend
智慧中台 · 微前端迁移
qiankun 渐进迁移，把 4 个业务团队从单体同步发版中解耦出来：选型决策、迁移六阶段、关键设计、15 个坑与量化效益。
qiankunVue3Vite渐进迁移
21 → 2.3min构建时间 -89.2%
+40%交付效率
4业务团队解耦
智慧中台 · 微前端迁移
qiankun 渐进迁移，把 4 个业务团队从单体同步发版中解耦出来，统一权限 / 路由 / 灰度与回滚。
30 秒电梯版
智慧中台是一个跑了三年的单体 Vue 应用，4 个业务团队共用一个仓库，任何小需求都要走同一个构建和发布流程，一次构建 21 分钟、发版要排队、一处改动可能崩全站。我主导把它按业务域拆成一个主应用 + 多个子应用，用 qiankun 做基座，主应用统一收敛登录态、权限、菜单和路由分发，子应用独立仓库、独立开发、独立部署。关键在于没有停机：老模块以路由级粒度渐进式迁移。过程中真正花时间的不是接 qiankun，是沙箱、样式隔离、公共依赖、通信时序四类问题。最终构建 21min → 2.3min，故障影响范围从「全站」收敛到「单个子应用」。
为什么要迁：把痛点变成数字
| 维度 | 单体痛在哪 |
|---|---|
| 构建时长 | 全量 21 分钟，改一行也要等 |
| 发布节奏 | 统一发版，一个团队没准备好全员卡住 |
| 技术栈 | 锁定旧版本，升级牵一发动全身 |
| 故障半径 | 任一模块报错可能白屏全站 |
| 组织 | 4 团队改同一份路由表，必冲突 |
一句话：单体的瓶颈不在性能，在组织协作——微前端解决的首要问题是解耦发布权。
选型决策
| 方案 | 隔离能力 | 体验 | 改造成本 | 判断 |
|---|---|---|---|---|
| iframe | 最强 | 差（路由不同步/弹窗被裁） | 低 | ✗ 用户体验不能退 |
| qiankun | 好（沙箱+样式隔离） | 好 | 中 | ✓ 选中（存量渐进迁移） |
| Module Federation | 弱 | 好 | 中高 | △ 存量改造成本高 |
| wujie | 很强 | 好 | 中 | △ 当时生态/熟悉度不如 qiankun |
选 qiankun 三条理由：① 渐进迁移（路由级接入，存量系统唯一活路）；② 开箱隔离（自研隔离成本远超收益）；③ 技术栈无关（Vue2/Vue3/React 都行）。
迁移六阶段
盘点 → 划界 → 基座 → 试点 → 批量 → 收尾。
- 盘点：产出模块清单（路由/负责人/依赖/PV/bug 数）+ 依赖关系图，找到 2-3 个边界清晰、改动频繁的域作首批。
- 划界（最易做错）：按业务域拆，不按技术分层拆（权限中心/资产管理，而非 header-app/table-app）。主应用只留横切能力，绝不放业务组件。
- 基座：主应用持顶层路由表；token 存主应用 props 下发；权限双层（路由级 + 按钮级）。
- 试点：选最小最独立模块先迁，产出《子应用接入 SOP》。
- 批量：路由级灰度（新旧路由并行、配置开关切流、一键切回）。
- 收尾：清老路由/老配置，上子应用维度监控 + CI 门禁。
关键设计
- 样式隔离：构建期 PostCSS 加前缀（主力）+ 弹层统一
getPopupContainer+ experimentalStyleIsolation 兜底。难点是隔离挂到 body 上的那部分样式（弹窗/抽屉/下拉）。 - JS 沙箱：ProxySandbox 只拦
window.xxx属性读写，拦不住事件监听、定时器、DOM 副作用——用副作用收集器在 unmount 统一清理。 - 通信：props（主→子上下文）> initGlobalState（广播）> 事件总线（通知，成对 on/off）。
- 公共依赖：Vue/UI 库/axios 走 externals 统一共享，锁大版本，主应用先升。
- 灰度回滚：路由级开关（按用户/租户/百分比切流），切回老路由即可，不依赖重建。
坑清单（15 条核心）
| # | 坑 | 根因 |
|---|---|---|
| 1 | 弹窗/抽屉样式全丢 | 挂到 body，跑出隔离范围 |
| 2 | 子应用样式污染全局 | 全局 CSS 未加前缀 |
| 3 | 定时器越跑越多 | setInterval 未清，沙箱不拦 |
| 4 | 打包后资源 404 | publicPath 写死 |
| 5 | 主子发版不同步状态错乱 | 契约无版本兼容 |
| 6 | Vue/UI 库加载两份 | 公共依赖未 external |
| 7 | 子应用本地开发困难 | 未做独立运行入口 |
| 8 | 刷新 404 | history base 与 fallback 未配 |
| 9 | 首屏并发风暴 | prefetch all 抢带宽 |
| 10 | mount 拿不到全局状态 | 通信时序问题 |
| 11 | 发版后用户仍老页面 | HTML Entry 被缓存 |
| 12 | 三方库沙箱报错 | 依赖 window 真实性 |
| 13 | 版本矩阵爆炸 | 独立发版组合态失控 |
| 14 | 主题/国际化不生效 | 读不到或读快照 |
| 15 | 埋点/错误归属混乱 | 上报归属规则未定 |
量化结果与代价
- 4 个业务团队解耦；构建 21min → 2.3min（↓89.2%）；交付效率 +40%；故障半径收敛到单个子应用；回滚秒级。
收益是真的，但代价也真实存在：首屏多一层加载（预取 + 公共依赖共享压回）、调试复杂度上升（补跨应用 trace）、版本矩阵是新的测试负担（发布清单 + 契约测试）。
什么时候不该上微前端
- 只有一个团队/一个业务域 → 拆了收益为零
- 模块间耦合极深 → 先解耦
- 应用体量不大（20 页面内）→ 升级构建工具就够
- 团队没有自动化测试和监控 → 微前端把编译期错误变运行期错误
金句：微前端是「组织架构的镜像」——解决多团队独立发布的问题。技术问题用技术解，组织问题才用架构解。