代码拆开不难，难的是团队协作和体验不碎。
微前端架构_高清.png
微服务架构在后端已经很成熟了，但前端还在探索阶段。微前端（Micro Frontends）的概念提出后，很多团队都想尝试，但实际落地时发现：代码拆开不难，难的是团队协作和用户体验不碎片化。今天就来聊聊微前端架构演进路上的那些坑。
为什么需要微前端？
核心优势
1. 团队独立：不同团队可以独立开发、部署前端应用，减少协调成本。
2. 技术栈自由：不同子应用可以用不同的框架（React、Vue、Angular），适合渐进式迁移。
3. 独立发布：子应用可以独立发布，不影响其他应用。
适用场景
✅ 大型应用，多个团队协作
✅ 需要渐进式迁移老系统
✅ 不同业务模块技术栈不同
不适用场景
❌ 小团队、小项目
❌ 应用之间耦合度高
❌ 没有独立部署需求
架构模式选择
1. 构建时集成
• 子应用作为 npm 包发布
• 主应用构建时集成
• 优点：简单，性能好
• 缺点：需要重新构建主应用
2. 运行时集成
• 子应用独立部署，运行时加载
• 优点：真正独立部署
• 缺点：复杂度高，性能开销
3. iframe 集成
• 最简单的方案
• 优点：完全隔离
• 缺点：体验差，通信复杂
推荐方案：对于大多数场景，运行时集成（Module Federation 或 Single-SPA）是最佳选择。
核心问题与解决方案
1. 统一设计系统
问题：不同子应用 UI 风格不一致，用户体验碎片化。
解决方案：
• 建立统一的设计系统（Design System）
• 公共组件库统一发布
• 样式变量（CSS Variables）统一管理
• 定期设计评审
微前端设计系统_高清.png
实践：
// js// 主应用提供设计 tokenwindow.__DESIGN_TOKENS__ = {colors: { primary: '#1890ff', ... },spacing: { small: '8px', ... },typography: { ... },};// 子应用使用const primaryColor = window.__DESIGN_TOKENS__.colors.primary;2. 路由治理
问题：多个子应用的路由可能冲突，导航体验不一致。
解决方案：
• 主应用持有全局路由表
• 子应用注册路由前缀
• 统一的路由跳转 API
实践：
// js// 主应用路由配置const routes = [{ path: '/app1/*', app: 'app1' },{ path: '/app2/*', app: 'app2' },];// 子应用注册路由window.__MAIN_APP__.registerRoutes('/app1', [{ path: '/dashboard', component: Dashboard },{ path: '/settings', component: Settings },]);3. 共享依赖
问题：多个子应用重复打包相同依赖，体积大，版本冲突。
解决方案：
• 公共依赖 external，由主应用提供
• 版本统一管理
• 使用 Module Federation 共享模块
实践（Webpack Module Federation）：
// js// 主应用 webpack.config.jsmodule.exports = {plugins: [new ModuleFederationPlugin({name: 'host',remotes: {app1: 'app1@http://localhost:3001/remoteEntry.js',app2: 'app2@http://localhost:3002/remoteEntry.js',},shared: {react: { singleton: true },'react-dom': { singleton: true },},}),],};通信机制
事件总线
最简单的方案，但容易混乱。
// js// 主应用提供事件总线window.__EVENT_BUS__ = new EventEmitter();// 子应用通信window.__EVENT_BUS__.emit('user-login', { userId: '123' });window.__EVENT_BUS__.on('user-logout', () => { ... });状态共享
用 Redux 或 Zustand 共享全局状态。
// js// 主应用提供 storewindow.__GLOBAL_STORE__ = createStore(...);// 子应用使用const user = window.__GLOBAL_STORE__.getState().user;Props 传递
主应用通过 props 传递数据给子应用。
权限与鉴权
统一鉴权：
• 主应用统一处理登录、token 刷新
• 子应用通过 API 获取用户信息
• 路由级权限控制由主应用管理
实践：
// js// 主应用提供鉴权 APIwindow.__AUTH__ = {getUser: () => fetch('/api/user'),hasPermission: (permission) => { ... },logout: () => { ... },};// 子应用使用const user = await window.__AUTH__.getUser();if (!window.__AUTH__.hasPermission('admin')) {// 无权限处理}性能优化
懒加载
子应用按需加载，减少首屏体积。
// jsconst App1 = lazy(() => import('app1/App'));预加载
预加载可能用到的子应用。
// js// 鼠标悬停时预加载onMouseEnter={() => {import('app1/App');}}缓存策略
• 子应用资源长期缓存（content hash）
• 主应用资源短期缓存
• 使用 Service Worker 做离线缓存
监控与调试
错误监控
• 统一错误上报
• 区分主应用和子应用错误
• 错误边界（Error Boundary）隔离
性能监控
• 子应用加载时间
• 子应用渲染时间
• 主应用与子应用交互延迟
调试工具
• 开发环境显示当前加载的子应用
• 子应用切换日志
• 通信事件日志
常见问题
问题1：样式冲突
• 使用 CSS Modules 或 styled-components
• 子应用样式加前缀
• Shadow DOM 隔离（可选）
问题2：全局变量污染
• 使用命名空间
• 避免修改全局对象
• 代码审查检查
问题3：版本冲突
• 统一依赖版本
• 使用 Module Federation 共享
• 定期更新依赖
问题4：体验不一致
• 统一设计系统
• 统一交互规范
• 定期用户体验评审
迁移建议
如果你是从单体前端应用迁移：
1. 评估必要性：真的需要微前端吗？
2. 选择方案：构建时集成 vs 运行时集成
3. 试点项目：先迁移一个模块，验证效果
4. 建立规范：设计系统、通信协议、部署流程
5. 逐步推广：积累经验后，逐步迁移其他模块
小结
微前端是工程策略，不是银弹。要注意：
✅ 先验证业务拆分合理性：业务边界清晰，再考虑技术拆分
✅ 统一规范：设计系统、通信协议、部署流程
✅ 性能优化：懒加载、预加载、缓存策略
✅ 监控到位：错误监控、性能监控、用户体验监控
