过去几年微前端被讨论得挺多，但真正落地时大家还是容易陷入“架构过重”“改造成本高”“发布流程复杂”等现实问题。我最近在一个内部运营系统里做了一次“渐进式微前端”改造，实践下来效果挺不错，踩坑也不少，这里简单分享下。
为什么我们需要微前端？
原项目是典型的巨石应用，React + Antd，代码量 20w 行左右，构建一次要等 2 分钟，最尴尬的地方是：不同业务线互相等待上线。你前端改个样式，也要卡在别人的功能开发里，大家都在同一个 Git 仓库，冲突不断，合代码非常心累。
于是我们决定按业务域拆分，但又不想直接上 qiankun 那种“一刀切式”的架构，所以走了更轻量的办法。
我们选的方案：渐进式接入
核心思路只有两条：
- 主应用做“外壳” + 路由分发
- 业务应用 independent build，通过动态加载 bundle 接入
一开始我们只改了一个最简单的模块作为试点，通过 <script src="xxx/entry.js"> 的方式挂载子应用。你可能会觉得这个方式土，但好处是非常稳定，构建和接入完全不耦合。
渐进式做的好处是：
✔ 老系统不需要大改
✔ 没有跨框架、跨版本的问题
✔ 可以随时 rollback，风险极低
✔ 子应用团队可以独立开发、独立发布
实际踩过的几个坑
1. 样式隔离
我们没有用 Shadow DOM，而是用了 scoped CSS + BEM + 全局 reset 的方式。因为运营后台对 UI 要求没那么严格，Shadow DOM 带来的边界问题反而麻烦。
2. 全局状态共享
我们没有搞 Redux 全局通信，而是用了一套 EventEmitter。事实证明 90% 的通信只需要 window.dispatchEvent() 就能解决。
3. 权限体系拆分
老系统的权限校验在 router 里，而子系统并不知道 router 环境。最终做法是：主应用负责 “canActivate”，子应用只负责渲染。不要试图让子应用包含业务权限逻辑，不然后期维护会撑不住。
效果怎么样？
- 构建从原来的 2 分钟 → 现在 20 秒
- 子应用能独立发版，出现问题可以快速 rollback
- 业务团队之间边界更清晰
整体体验下来，这种轻量的做法非常适合内部管理系统，有计划拆微前端的团队可以借鉴。
