微前端落地，我差点被产品经理送走
去年双11前两周，我正窝在沙发上用MacBook Pro敲代码，远程连着公司内网，一边喝冰美式一边改一个祖传的Vue 2项目。突然钉钉“叮”一声，项目经理发来消息：“老板拍板了，下周起老系统要拆成微前端，你负责技术选型和落地。”
我当时手一抖，咖啡差点洒在键盘上——这活儿，听起来就像是那种“既要马儿跑，又要马儿不吃草”的经典外包需求。
我是谁？一个在二线外包公司混了4年的前端老兵，写过从jQuery到React 18的代码，见过产品经理画出“五彩斑斓的黑”这种需求，也经历过测试凌晨三点提bug说“页面点不动，但重启浏览器就好了”。家里两台显示器，一台Mac主力开发，一台Windows专门用来测兼容性——别笑，IE11虽死，幽灵仍在。
所以，当“微前端”这三个字砸下来时，我第一反应不是兴奋，而是：这玩意儿真能救我们这个屎山项目？
背景：为什么非得上微前端？
我们的客户是个大型国企，内部系统有十几个，但UI风格五花八门，登录一次跳转七八次，后端接口更是横跨Java、.NET、甚至还有PHP写的遗留模块。最离谱的是，每个子系统都由不同外包团队维护，版本发布互不协调，经常A系统更新完，B系统就崩了。
老板的想法很朴素：统一入口、统一登录、统一UI，但各团队还能独立开发部署。
翻译成人话：你们前端搞个壳子，把所有子应用塞进去，看起来像一个系统，但开发还是各干各的。
这不就是微前端的典型场景吗？理论上，yes。但实操起来，坑比代码还多。
技术选型：Qiankun 还是 Module Federation？
我一开始想上 Webpack 5 的 Module Federation，毕竟新、快、原生支持。但现实狠狠打了我脸：
- 客户要求支持 IE11（对，你没看错，2023年还有IE11）
- 多个子应用技术栈不统一：Vue 2、Vue 3、React 16、甚至还有 AngularJS
- 后端兄弟表示：“我们不想改任何部署方式，子应用还是单独部署，你前端自己搞定加载”
行吧，Module Federation 直接出局。最后咬牙上了 Qiankun，蚂蚁开源的微前端框架，社区成熟，兼容性好，还能手动处理沙箱隔离。
// 主应用注册子应用
registerMicroApps([
{
name: 'user-center',
entry: '//localhost:8081',
container: '#subapp-container',
activeRule: '/user',
},
{
name: 'order-system',
entry: '//localhost:8082',
container: '#subapp-container',
activeRule: '/order',
}
]);
看起来简单，但真正上线那天，我差点连夜辞职。
踩过的坑：比面试题还刁钻
坑1：全局样式污染
子应用A用的是 Element UI，子应用B用的是 Ant Design，两个CSS变量名冲突，导致按钮颜色乱飞。
解决方案：强制要求所有子应用使用 CSS Modules 或 Scoped CSS，主应用加一层 :root 重置。
/* 主应用 reset.css */
:root {
--primary-color: #1890ff;
}
但有个外包团队死活不肯改，说“工期紧，改不了”。最后我只能在主应用里用 postcss-prefixwrap 给每个子应用自动加命名空间——属于是前端界的“物理隔离”了。
坑2：路由冲突 & 刷新白屏
Vue Router 和 React Router 各自管理自己的 history，主应用切换子应用时，URL 变了，但子应用没响应。更惨的是，用户直接刷新 /order/detail，主应用加载完，子应用还没注册，页面一片白。
解决办法：
- 主应用用
hash模式，子应用用memory模式 - 子应用挂载前，先判断是否在主应用中，再决定是否初始化路由
- 配合 Nginx 做 fallback，确保所有路径都指向主应用入口
location / {
try_files $uri $uri/ /index.html;
}
坑3：公共依赖重复加载
每个子应用都打包了 lodash、axios、moment，首屏加载慢得像蜗牛。
优化方案：
- 主应用提供公共依赖（通过
window挂载） - 子应用配置 externals，不打包这些库
// webpack.config.js (子应用)
externals: {
axios: 'axios',
lodash: '_',
}
但这就要求所有团队用同一版本的依赖——又是一场跨团队协调的噩梦。最后我们搞了个“公共依赖清单”，写进合同附件，谁乱升级谁请全组喝奶茶。
性能与体验：用户可不管你是微前端
微前端最大的风险，就是用户体验割裂。比如：
- 子应用切换时闪白屏
- 全局 loading 状态不统一
- 登录状态不同步
我们做了几件事：
- 预加载：用户 hover 导航时，提前加载子应用资源
- 统一 Loading：主应用提供全局 loading 组件，子应用通过 props 控制
- 共享状态：用
qiankun的initGlobalState实现登录态、用户信息同步
// 主应用
const actions = initGlobalState({ user: null });
actions.onGlobalStateChange((state, prev) => {
console.log('global state changed', state);
});
// 子应用
export const mount = (props) => {
props.onGlobalStateChange((state) => {
// 更新本地用户信息
});
};
上线后，用户反馈“好像变快了”，其实只是 loading 动画更顺滑了——前端玄学，懂的都懂。
后端配合：别以为微前端只是前端的事
很多人以为微前端是前端自嗨，其实后端支持至关重要。比如：
- CORS 问题：子应用域名不同，跨域请求需要后端配
Access-Control-Allow-Origin - 鉴权统一：所有子应用必须共用一套 token，后端得支持从 cookie 或 header 读取
- 日志追踪：用户操作跨多个子应用，需要统一 traceId
有一次，订单子应用调用用户中心接口失败，查了半天发现是后端没放行 origin: https://main-app.com。运维大哥一脸无辜：“你们前端不是自己搞定吗？”
我：……（内心OS：下次跳槽一定要问清楚后端配合度）
面试题 & 求职：微前端成了新考点
自从我们项目落地后，我发现微前端突然成了大厂面试高频题。上周帮朋友 mock 面试，被问到：
“Qiankun 的沙箱机制原理是什么？如何解决样式隔离和 JS 隔离？”
说实话，要不是自己踩过坑，光看文档根本答不深。现在求职市场上，会“微前端落地经验”的简历，确实比只会 CRUD 的吃香。但我也劝新人别盲目追：微前端是解药，也是毒药。项目不到一定规模，强行上微前端，纯属给自己找罪受。
最后一点真心话
微前端不是银弹，它解决的是组织协作问题，而不是技术问题。如果你的团队只有5个人，天天坐一起沟通，那单体应用可能更高效。但如果你像我们一样，面对十几个外包团队、几十个子系统、无数个 deadline，那微前端至少能让你睡个安稳觉——虽然可能只多睡两小时。
现在，我们的系统已经稳定运行半年，老板逢人就说“技术驱动业务”。而我，还在用 Mac 写代码，Windows 机灰了一层，偶尔拿来测一下 Edge 兼容性。
至于下个项目？听说又要上低代码平台了……
唉，打工人，打工魂，明天继续搬砖。
| 项目阶段 | 问题 | 解决方案 | 耗时 |
|---|---|---|---|
| 技术选型 | IE11兼容性 | 放弃Module Federation，选用Qiankun | 2天 |
| 样式隔离 | 全局CSS污染 | CSS Modules + 自动命名空间 | 3天 |
| 路由同步 | 刷新白屏 | 主应用hash + 子应用memory模式 | 2天 |
| 性能优化 | 重复加载依赖 | externals + 公共依赖清单 | 4天 |
| 用户体验 | 切换卡顿 | 预加载 + 统一Loading | 1天 |
总结一句话：微前端能落地，靠的不是技术多牛，而是沟通+妥协+一点点运气。
评论 0