微前端落地三年，我踩过的坑比天通苑早高峰的地铁还挤

三年前公司决定把膨胀到不敢碰的React单体项目拆成微前端。果然，接下来半年我基本住在工位上。

先说崩溃的坑：样式污染。我们用qiankun，以为沙箱能搞定一切。结果上线第一周，子应用A的全局CSS把子应用B的按钮样式覆盖了。查了半天，发现子应用A里有人写了button { color: blue; }。后来强制所有子应用必须用CSS Modules，再配合qiankun的shadow DOM模式，才消停。

第二个坑是公共依赖重复加载。React、ReactDOM、moment每个子应用都打包一份，首屏慢得像早高峰的5号线。我们把React和ReactDOM通过externals抽出来用CDN加载，moment换成dayjs，首屏从8秒降到3秒。

生成式AI这三年帮了大忙。去年我开始用Mistral辅助排查微前端疑难杂症。有次子应用通信死活不通，我把代码和报错粘给Mistral，它直接指出全局状态管理里有个变量名拼错了——userInfo写成了userinfo。这种低级错误，AI一眼看出，我却得查一下午。现在我的工作流是：遇到诡异bug，先自己查半小时，查不出来就扔给Mistral，十次有七次能定位问题。

还有一次，子应用路由切换白屏。把代码喂给Mistral后，它建议检查unmount阶段是否清理了全局事件监听。我一看，果然有个resize监听没移除，每次切换都叠加一个，切几次就内存泄漏了。

三年下来，微前端确实解决了单体应用的问题：独立部署、技术栈隔离、团队解耦。但复杂度也不小——样式隔离、公共依赖管理、通信机制、监控告警，每样都得花心思。我的经验是：如果你的项目没有大到必须拆，就别拆。微前端不是银弹，它是把一个大坑拆成几个小坑，没准备好填坑的人手和时间，只会更痛苦。

上周五那个报错，最后发现是子应用D的某个依赖升级后和主应用的qiankun版本不兼容。我回滚了依赖版本，加了条注释：“别乱升级，除非你想让老李凌晨三点还在改bug。”老李就是我。

35岁还在写代码不丢人，丢人的是35岁还写不好代码。微前端也好，生成式AI也好，工具在变，但解决问题的耐心和细心不会变。Mistral能帮我查bug，但查完bug之后怎么优化架构、怎么跟团队沟通，还得靠我自己。

如果你也在做微前端，送你一句话：别急着上，先想清楚为什么上。想清楚了，坑一个都不会少，但至少你摔下去的时候心里有数。