微前端不是银弹，但救了我司那个祖传大项目
上周五晚上十一点半，我合上 MacBook 的瞬间，房贷还款短信刚好弹出来。那一刻我突然意识到：这破班非上不可，但代码得写得聪明点。
其实这篇文章的起因特别现实——我想跳槽。最近在刷 LeetCode 和啃 AI 课程的同时，也在复盘自己手头项目的架构。毕竟面试官最爱问：“你做过什么有挑战性的项目？” 而我们那个“祖传 React 单体应用”，曾经让我连续三天梦见 Maximum call stack size exceeded。
一切始于产品经理的一句“小需求”
去年双11前一个月，产品老大在站会上轻描淡写地说：“咱们要把会员中心、订单系统、营销活动三个模块拆成独立团队开发，但用户看到的还是一个网站。”
我当场就想问他：您知道这三个模块共享同一个 Redux store、互相 import 组件、甚至共用一套 CSS 全局变量吗？
更惨的是，后端那边早就微服务化了，每个业务域都有自己的 API 网关。结果前端还卡在“巨石时代”——改个按钮颜色，CI/CD 跑半小时，上线还得全量回归测试。运维兄弟每次看到我们的构建日志都摇头：“你们前端是不是把整个 npm_modules 打包进去了？”
为什么选微前端？因为别无选择
说实话，一开始我对微前端持怀疑态度。网上各种声音：“微前端是架构师的玩具”、“增加了复杂度”、“不如多搞几个 SPA”。但现实很骨感：
- 团队扩张到 30+ 前端，Git 冲突天天见
- 新人入职两周还在看全局状态管理逻辑
- 某次 A/B 测试因为 CSS 冲突导致整个支付页面错位（差点被财务追杀）
技术选型时，我们对比了几种方案：
| 方案 | 隔离性 | 构建速度 | 学习成本 | 跨框架支持 |
|---|---|---|---|---|
| Module Federation (Webpack 5) | 中 | 快 | 中 | 弱（需同构建工具） |
| qiankun | 高 | 中 | 低 | 强（React/Vue/Angular） |
| iframe | 极高 | 快 | 极低 | 任意 |
| 自研沙箱 | 极高 | 慢 | 极高 | 灵活 |
最终选了 qiankun ——不是因为它最完美，而是它让我们能用最小代价快速落地。毕竟作为背房贷的北漂，哪有时间造轮子？而且我们主应用和子应用都是 React，版本也统一到了 18.x。
注：其实偷偷用 ChatGPT 生成过 Module Federation 的 demo，但发现老旧组件里那些
window.xxx = ...的写法根本跑不起来，果断放弃。
踩坑实录：那些让我想砸键盘的时刻
坑 1：CSS 样式污染比想象中更顽固
原以为用了 qiankun 的沙箱机制就万事大吉，结果子应用里一个 .container { width: 100% } 直接把主应用的导航栏撑爆了。
解决方案：强制约定 CSS 命名空间 + CSS-in-JS 迁移计划
/* 错误示范 */
.container { ... }
/* 正确姿势 */
.member-center-container {
/* 或者用 BEM */
.member-center__container { ... }
}
更狠的是，我们后来直接在 ESLint 里加了规则：禁止使用通用类名。虽然被同事吐槽“矫枉过正”，但上线后没再出过样式事故。
坑 2：公共依赖怎么共享？
最初每个子应用都打包了 React、Lodash、Axios... 用户每次切 tab 就要重复下载 2MB 的 JS。Chrome DevTools 里的 Network 面板红得发紫。
关键配置（主应用 webpack 配置）：
// 主应用暴露共享依赖
new ModuleFederationPlugin({
name: "host",
shared: {
react: { singleton: true, requiredVersion: "18.2.0" },
"react-dom": { singleton: true, requiredVersion: "18.2.0" },
axios: { singleton: true, requiredVersion: "1.4.0" }
}
})
子应用也要做对应配置，否则会报 Invalid hook call。这里特别感谢 Claude 帮我调试配置文件——没有它我可能还在和 Webpack 的 shared 配置搏斗。
坑 3：登录态同步的“幽灵问题”
用户在主应用登录后，切换到子应用却显示未登录。查了半天发现：Cookie 的 Path 不一致！主应用是 /，子应用部署在 /member/ 下。
临时方案是在主应用登录成功后，通过 props 传递 token 给子应用：
// 主应用
<SubApp token={localStorage.getItem('auth_token')} />
// 子应用入口
export const mount = (props) => {
if (props.token) {
localStorage.setItem('auth_token', props.token);
}
// ...渲染
}
长期方案是推动后端统一认证服务，用 JWT 替代 Session。不过这事得等后端大佬排期——他们正忙着重构订单微服务呢。
性能数据：真香警告
落地三个月后，我们做了对比测试（MacBook Pro M1, Chrome 118）：
| 指标 | 单体应用 | 微前端架构 | 提升 |
|---|---|---|---|
| 首屏加载 | 4.2s | 1.8s | 57% ↓ |
| 切换模块耗时 | 2.1s | 0.3s | 86% ↓ |
| 构建时间 | 280s | 45s（增量） | 84% ↓ |
| Bundle 大小 | 8.7MB | 主应用 2.1MB + 子应用均 1.5MB | - |
最爽的是：现在改会员中心的代码，再也不用担心影响支付流程。上周五我甚至提前下班去看了房——虽然只是路过中介橱窗（狗头保命）。
给想跳槽同学的建议
如果你正在准备求职，千万别只背八股文。我在最近的面试中，把微前端落地过程讲成“如何在技术债深重的项目里做渐进式改造”，反而比单纯讲原理更打动面试官。
几个加分项：
- 量化结果：像上面表格那样给出具体数据
- 承认局限：我说“微前端增加了调试复杂度，我们通过自研调试面板解决”
- 关联业务：强调“因为双11流量压力，我们必须降低首屏时间”
顺便安利个技巧：用 ChatGPT 模拟面试官追问。比如让它问：“如果子应用用 Vue3，主应用用 React18，怎么做状态共享？”——这招帮我发现了 qiankun 的 globalState 机制。
最后说点人话
微前端不是银弹，它解决的是组织架构问题而非纯技术问题。如果你的团队只有 5 个人，别折腾这个。但当你的 Git 提交记录里出现“fix: 紧急修复因 xx 修改导致的 yy 模块崩溃”这种 message 时，该考虑拆分了。
现在的我，白天写业务代码，晚上刷题学 AI，周末研究房贷利率。技术人的生活大概就是这样：一边在代码里追求解耦，一边在现实中被各种东西紧紧耦合着。
对了，文章里没提 iframe 方案不是因为它不好——而是产品经理上次说“我们要无缝体验”，而 iframe 的滚动条和 SEO 问题实在没法忍。要是哪天他改口说“能用就行”，我立马切回去（逃）。
评论 0