微前端架构在大型项目中的落地经验
上周五晚上 11 点，我坐在工位上盯着屏幕上密密麻麻的 Git 提交记录，心里默默祈祷明天上线别炸。作为深圳某三线互联网公司的技术负责人（对，就是那种离腾讯总部不到 5 公里但工资只有一半的公司），最近半年一直在折腾微前端的事儿。说来惭愧，平时写代码还是 Vim 党，IDE 都快生锈了，但这次真不是我想折腾——是产品经理拿着“平台化战略”的 PPT 来找我谈心，说要“快速迭代、灵活部署、团队自治”…… 好吧，我懂，就是想让我把锅甩给架构。
为啥要搞微前端？
去年双11前一个月，我们有个内部管理后台突然要加一个供应链模块。本来以为就是个 CRUD 页面，结果一问才知道，这模块背后连着 ERP、WMS、TMS 三个老系统，而且开发团队在深圳、成都、杭州三地。最要命的是，主应用是 Vue 2 + Element UI 写的，而成都团队只会 React + Ant Design。
当时我真的想砸电脑。总不能让成都兄弟改用 Vue 吧？人家刚培训完 React hooks；也不能让我们重写整个后台吧？测试同学听到这个消息差点当场辞职。
就在那个深夜加班的凌晨三点，我在 GitHub 上刷到了 qiankun —— 阿里开源的微前端方案。点进去一看，文档居然挺全，Star 数也过了 10k。抱着“死马当活马医”的心态，我 fork 了一份，开始研究。
踩坑实录：从“Hello World”到线上炸服
微前端听起来很美好：主应用加载子应用，各团队独立开发部署，互不影响。但现实永远比文档残酷。
第一个坑：样式隔离
子应用加载进来后，Element UI 的 button 样式直接被 Ant Design 的覆盖了！页面乱成一锅粥。查了半天才发现，qiankun 默认的沙箱只能隔离 JS，CSS 还是要靠自己。
解决方案很简单但容易忽略：
// 主应用注册子应用时开启 scoped css
registerMicroApps([
{
name: 'supply-chain',
entry: '//localhost:8081',
container: '#subapp-container',
activeRule: '/supply-chain',
props: {
// 开启 CSS 沙箱
sandbox: { strictStyleIsolation: true }
}
}
]);
不过 strictStyleIsolation 会用 Shadow DOM，IE11 直接躺平。我们最后折中用了 experimentalStyleIsolation，靠 CSS prefix 实现隔离，虽然不完美但能跑。
第二个坑：公共依赖重复加载
每个子应用都打包了自己的 Vue、Lodash、Axios…… 首屏加载时间从 2s 暴涨到 6s。用户投诉“点一下卡半天”，运维群里天天@我。
后来我们搞了个“共享依赖”机制，在主应用里通过 webpack externals 把公共库抽出来：
// webpack.config.js
externals: {
vue: 'Vue',
'element-ui': 'ELEMENT',
axios: 'axios'
}
然后子应用在入口处判断是否已存在：
// 子应用 main.js
if (!window.Vue) {
import('vue').then(Vue => {
window.Vue = Vue.default;
initApp();
});
} else {
initApp();
}
虽然有点 hack，但首屏性能立马回到 2.3s，用户不再骂娘了。
第三个坑：本地开发体验极差
微前端最大的痛点其实是开发体验。以前改个代码 npm run dev 就行，现在要同时启动主应用 + N 个子应用，端口冲突、跨域问题、热更新失效…… 新来的实习生第一天就问我：“哥，这玩意儿能 debug 吗？”
我们最后搞了个脚本一键启动所有服务：
# dev.sh
concurrently \
"cd main-app && npm run dev" \
"cd subapp-supply && npm run dev" \
"cd subapp-finance && npm run dev"
配合 proxy 配置解决跨域：
// vite.config.js (主应用)
server: {
proxy: {
'/api/supply': 'http://localhost:8081',
'/api/finance': 'http://localhost:8082'
}
}
虽然还是不如单体应用爽，但至少不用每次改代码都重启全家桶了。
性能与兼容性：别让用户为你的架构买单
微前端最容易被忽视的就是用户体验。我们上线第一周，就有用户反馈“切换子应用时白屏太久”。打开 DevTools 一看，子应用 bundle 有 2.4MB！
于是我们做了几件事：
- 预加载：在用户可能进入的路由前，提前加载子应用资源
- 骨架屏：子应用加载时显示 loading skeleton，而不是白屏
- 缓存策略：子应用资源加上 hash，配合 long-term cache
// 预加载示例
import { start, prefetchApps } from 'qiankun';
prefetchApps([
{ name: 'supply-chain', entry: '//cdn.example.com/supply' }
]);
start();
至于浏览器兼容性…… 我们公司还在用 IE11 的客户占 12%（别问，问就是政企客户）。微前端 + IE11 简直是地狱 combo。最后不得不放弃 Shadow DOM，用 CSS Module + BEM 命名规范手动隔离，还 polyfill 了一堆 ES6 API。
效果如何？值不值得搞？
上线三个月后，数据说话：
| 指标 | 微前端前 | 微前端后 | 变化 |
|---|---|---|---|
| 平均发布周期 | 2周 | 2天 | ↓90% |
| 跨团队协作成本 | 高（需联调） | 低（独立部署） | ↓70% |
| 首屏加载时间 | 2.1s | 2.3s | ↑9.5% |
| 线上事故率 | 月均3次 | 月均1次 | ↓66% |
虽然首屏略慢一点，但团队效率提升是实打实的。成都团队现在可以随时上线他们的模块，再也不用等我们排期。产品经理也不再半夜打电话问我“能不能先上一半功能”。
最重要的是，我们终于不用在同一个 Git 仓库里互相踩脚了。以前 merge request 动不动 conflict 一屏，现在各玩各的，peace & love。
给新手的一点建议
如果你也在考虑微前端，我的血泪经验总结如下：
- 别为了微而微：如果团队就 5 个人，搞微前端纯属自虐
- 先做技术验证：花一周时间搭个 demo，验证核心流程（加载、通信、隔离）
- 重视开发体验：工具链不完善的话，团队会恨死你
- 监控必须跟上：子应用加载失败、JS 报错要能及时告警
- GitHub 是你的好朋友：多看 issue，很多坑别人已经踩过了
最后说句实在话：微前端不是银弹，它解决的是组织架构问题，而不是技术问题。如果你的团队沟通顺畅、发布流程高效，那真的没必要上。但如果你像我一样，夹在多地团队、老旧系统、激进产品之间…… 那微前端可能是你最后的救命稻草。
对了，我们基于 qiankun 改造的内部框架已经整理了一部分放到 GitHub 了（虽然文档还没写完 😅），感兴趣的朋友可以搜 sz-micro-fe，欢迎提 issue 一起踩坑。
好了，凌晨 1 点了，该回家了。希望明天上线顺利，阿弥陀佛。
评论 0