微前端
先把“微前端”讲回它真正的问题域
微前端最容易被讲成一种高级前端拼装术。
比如：
- 把多个前端应用拼在一起
- 可以独立部署
- 像微服务一样拆前端
这些说法都抓到了一部分现象。
但如果只停在这里，会非常容易误导团队。
更准确的理解应该是：
微前端不是一个前端炫技方案，而是一种试图把大型前端系统的组织边界、交付边界和运行时边界做对齐的架构方法。
这句话里最重要的是三个边界：
- 组织边界
- 交付边界
- 运行时边界
只要这三个边界没有真实张力，微前端大概率就不是你最值得优先考虑的答案。
它首先是组织问题，不是技术时髦问题
Martin Fowler 那篇经典文章之所以直到今天还有参考价值，并不是因为它列了一堆技术细节。
而是因为它抓住了微前端真正出现的土壤：
前端规模和组织复杂度已经大到，单一代码库、单一发布节奏、单一团队协作模式开始成为瓶颈。
也就是说，微前端通常不是为了解决：
- 某个组件太大
- 某个页面不好写
它更多是在解决：
- 多团队并行开发互相卡住
- 发布节奏被强绑
- 框架和依赖升级无法局部推进
- 一个前端仓库承载过多业务自治需求
如果没有这些现实问题，微前端通常会变成“为了分而分”。
一个更准确的定义
如果要用一句更成熟的话来定义：
微前端是一种把大型前端系统拆成多个可独立演进、可相对自治、但又需要在用户面前组合成统一体验的前端架构方式。
这个定义有几个关键词。
可独立演进
不是每次改一个子系统，都要等待整个主应用统一节奏。
可相对自治
不是完全无约束自治。
而是在明确平台规则下保留局部决策权。
统一体验
不是把多个站点简单堆在一起。
用户仍然应该感受到它是一个产品，而不是几个前端系统拼接后的展览馆。
为什么“独立部署”不是全部
很多团队一提微前端，就把“独立部署”当核心卖点。
它当然重要。
但如果把它当唯一目标，就会做出很多奇怪方案。
因为独立部署只是表层结果。
真正的问题是：
为什么你需要这种部署独立性？
常见合理原因包括：
- 不同业务线节奏差异大
- 风险希望局部控制
- 某个子域有自己的发布窗口
- 某个团队需要更快试错
如果回答不出这些原因，只说“我们想独立部署”，往往说明微前端的必要性还没成立。
微前端和普通模块化的区别
这是另一个常见误区。
很多团队其实需要的是：
- 更好的模块边界
- 更好的 Monorepo 组织
- 更清晰的包依赖
这些都很重要。
但它们不一定等于微前端。
普通模块化解决的重点通常是代码组织。
微前端解决的重点通常是：
- 团队自治
- 构建与发布边界
- 运行时组合
- 多应用协作
所以不要因为代码库太乱，就直接跳到微前端。
先把“代码模块化问题”和“系统自治问题”分开。
常见实现路线，到底在交换什么
路由级拆分
这是最容易被低估、但往往最实用的一类方案。
不同子系统在不同路由范围内运行。
优点是：
- 边界最清楚
- 共享最少
- 故障影响面更小
缺点是：
- 跨路由协同较弱
- 页面内细粒度组合能力有限
很多时候，团队真正需要的其实只是路由级拆分，而不是运行时级复杂组合。
iframe
iframe 常常被当成“很老的办法”。
这不完全公平。
它最大的价值是：
浏览器级隔离真的强。
当你最关心的是：
- 安全隔离
- 历史系统包袱
- 快速接入异构系统
iframe 仍然可能是现实世界里最便宜、最稳的一类解。
它的代价则是：
- 通信笨重
- 体验割裂风险更高
- 样式和路由整合较差
single-spa 类编排
这一类方案更强调应用级运行时组合和生命周期编排。
它适合：
- 多框架共存
- 多应用统一挂载
- 主应用负责编排
但它也会让主应用变成非常关键的协调中心。
所以它的难点并不只是接入。
而是：
谁来维护主编排层，谁来定义跨应用契约。
Module Federation
Module Federation 之所以被广泛讨论，是因为它把“运行时共享模块和依赖”这件事做成了更强的工程能力。
它特别适合：
- 共享组件
- 在大系统里做部分运行时组合
- 希望保持相对现代工程体验的团队
但它并不是“微前端银弹”。
它更像是：
一套很强的运行时模块组合能力。
至于是否应该因此走向微前端，还要回到组织和系统边界判断。
Web Components
Web Components 的价值通常在：
- 标准化封装
- 跨框架复用
- 组件边界清晰
它有时适合作为微前端系统中的一层技术手段。
但它本身并不自动等于微前端架构。
微前端最难的，从来不是“能不能跑起来”
很多团队第一次做微前端，最兴奋的点是：
多个应用终于能挂到同一个壳里了。
但这往往只是开始。
真正困难的是后面的系统问题。
例如：
- 体验一致性
- 错误边界
- 样式治理
- 版本协同
- 发布顺序
- 调试复杂度
- 监控归因
也就是说，微前端的难点不在 demo。
而在长期运营。
样式隔离为什么经常成为第一波事故点
只要多个前端系统出现在同一页面里，样式冲突就是高概率事件。
常见方案包括：
- CSS Modules
- BEM 约定
- CSS-in-JS 局部作用域
- Shadow DOM
但没有哪一种是零代价。
例如：
- Shadow DOM 隔离强，但也会影响一部分样式与主题能力
- 约定式命名简单，但长期纪律要求高
- CSS-in-JS 能力强，但运行时和调试复杂度可能上升
所以样式隔离不是“选一个技术就结束”。
它其实是在考验团队是否愿意把样式边界当成架构问题来治理。
应用间通信为什么不能靠临时变量糊过去
微前端一旦落地，应用间通信就会变得真实而痛苦。
因为系统很快会出现这些需求：
- 登录态同步
- 导航状态同步
- 事件广播
- 埋点统一
- 跨应用跳转
这时如果没有明确协议，团队最容易走向：
- 挂全局变量
- 互相调对方方法
- 靠 DOM 事件乱传
短期很快。
长期非常脆弱。
所以更成熟的做法是：
把跨应用通信看成契约设计问题，而不是临时技巧问题。
路由协调为什么是用户体验问题，不只是技术问题
微前端下的路由问题常常会表现成：
- 刷新后页面不对
- 子应用前进后退异常
- 某个子系统跳走整个主壳
- URL 语义不一致
这些表面看是技术问题。
本质上其实是用户体验和系统边界问题。
因为用户不会关心这是哪个子应用的路由。
用户只会觉得：
这个产品的导航是不是稳定、可预测。
所以路由协调的重点不是“谁来管理 history”那么简单。
而是：
整个产品是否仍然表现为一个统一系统。
共享依赖为什么既诱人又危险
微前端系统里，共享依赖通常是最具诱惑力的优化点。
因为它看起来能减少重复加载、统一 React 版本、节省体积。
但共享依赖也意味着：
- 版本耦合
- 隐式运行时约束
- 升级风险传播
所以这件事的关键不是“能不能共享”。
而是：
哪些东西共享以后收益大于耦合成本。
通常更适合共享的是：
- 框架基础设施
- 设计系统
- 核心工具包
而不是把一切依赖都尝试共享。
微前端最适合什么样的组织
这点非常重要。
微前端从来不是“越大越先进”的架构。
它更适合：
- 多团队并行
- 业务边界相对清楚
- 需要局部发布自治
- 有平台团队或明确规则维护者
不太适合：
- 单一团队
- 产品规模仍小
- 前端团队本身边界很模糊
- 还没有形成基本工程规范
如果连基础工程纪律都还没建立，直接上微前端通常只会把问题放大。
中国互联网语境里为什么微前端常常会被认真讨论
中国互联网场景里，大型中后台、运营系统、多个业务域并行推进是很常见的。
这些系统常常有：
- 多团队共建
- 多业务入口
- 高发布频率
- 历史系统并存
在这种环境下，微前端不是一个纯理论架构。
它经常是团队试图解决组织协作和历史包袱的现实手段。
这也是为什么像 qiankun 这类方案在中文社区里一直有强存在感。
因为很多团队面对的不是“要不要做最优架构”，而是“怎么让历史系统和新系统还能一起活下去”。
海外语境里为什么微前端评价更分化
海外社区对微前端一直有明显分歧。
原因不只是技术偏好。
也和产品形态有关。
很多海外 SaaS 产品更强调：
- 统一体验
- design system
- API consistency
- 团队对平台层的长期治理
所以他们更容易把微前端视为：
一种带来治理成本和体验风险的高代价方案。
这不是否定微前端。
而是提醒团队：
微前端的收益通常只有在足够强的组织张力下才成立。
什么时候不该用微前端
- 单一团队维护整个前端
- 主要问题只是代码库太乱
- 没有明确独立部署诉求
- 团队没有足够平台治理能力
- 产品更需要统一体验而不是自治边界
如果这些条件成立，优先级通常应该是：
- 模块化
- Monorepo 治理
- 设计系统
- 依赖边界治理
而不是立刻上微前端。
面试或技术分享里怎么讲更成熟
一个更成熟的回答可以是：
微前端不是把多个前端随便拼起来，而是试图把大型前端系统里的组织边界、交付边界和运行时边界做对齐。它最适合的不是“想做先进架构”的团队，而是那些确实有多团队自治、独立发布和历史系统并存压力的场景。
技术实现上，iframe、single-spa、Module Federation、Web Components 都只是不同取舍下的手段。真正困难的部分不在接入，而在样式隔离、通信契约、路由协调、共享依赖和长期治理。
实践建议
实践一：先做路由级拆分，不要一上来就做运行时拼装
观察：
- 组织边界是否因此变清晰
- 发布节奏是否真的受益
实践二：画一张跨应用契约图
至少明确：
- 谁拥有登录态
- 谁负责导航
- 谁负责埋点
- 谁能发哪些全局事件
实践三：复盘一次“为什么我们不该上微前端”
这个练习很重要。
因为能说清“不上”的理由，通常说明你真的理解了它的代价。