前端微前端架构：大型项目是解药还是新坑？

这种写法在初期没问题，但随着代码量激增，会出现以下隐患：

• 所有逻辑挤在一个仓库，构建和测试时间变长。
• 多人协作容易引发 Git 冲突，尤其是公共组件修改时。
• 任何微小改动都需全量回归，发布风险高。
• 技术栈被锁定，无法针对特定模块优化。

微前端实践方案

使用 Single-SPA 编排

Single-SPA 是目前比较成熟的微前端框架之一，它负责路由分发和应用生命周期管理。在主应用中注册各个子应用：

// 主应用配置
import { registerApplication, start } from 'single-spa';

// 注册微前端应用
registerApplication({
  name: 'header',
  app: () => import('@org/header'),
  activeWhen: (location) => true,
});

registerApplication({
  name: 'dashboard',
  app: () => import('@org/dashboard'),
  activeWhen: (location) => location.pathname === '/dashboard',
});

registerApplication({
  name: 'settings',
  app: () => import('@org/settings'),
  activeWhen: (location) => location.pathname === '/settings',
});

registerApplication({
  name: 'user-profile',
  app: () => import('@org/user-profile'),
  activeWhen: (location) => location.pathname === '/user-profile',
});

// 启动应用
start();

这里要注意 activeWhen 的判断逻辑，确保路由匹配准确，避免多个应用同时激活导致的冲突。

子应用封装

每个子应用需要遵循特定的生命周期规范，React 结合 single-spa-react 可以简化这个过程：

// dashboard 微前端入口
import React from 'react';
import ReactDOM from 'react-dom';
import singleSpaReact from 'single-spa-react';

function Dashboard() {
  return (
    <div className="dashboard">
      <h1>Dashboard</h1>
      <p>Welcome to your dashboard!</p>
    </div>
  );
}

const reactLifecycles = singleSpaReact({
  React,
  ReactDOM,
  rootComponent: Dashboard,
  errorBoundary(err, info, props) {
    return <div>An error occurred: {err.message}</div>;
  },
});

export const bootstrap = reactLifecycles.bootstrap;
export const mount = reactLifecycles.mount;
export const unmount = reactLifecycles.unmount;

这样主应用就能通过标准接口控制子应用的挂载和卸载。

样式与通信隔离

样式污染是微前端的老大难问题。推荐使用 CSS Modules 或 Shadow DOM 进行隔离，确保组件样式只作用于当前作用域：

/* 使用 CSS Modules 或 Shadow DOM */
.dashboard {
  background-color: #f5f5f5;
  padding: 20px;
}

跨应用通信则建议通过全局事件或专用状态管理工具，避免直接依赖 DOM：

// 自定义事件通信示例
// 发送消息
function sendMessage(message) {
  window.dispatchEvent(new CustomEvent('micro-frontend-message', { detail: message }));
}

// 接收消息
window.addEventListener('micro-frontend-message', (event) => {
  const message = event.detail;
  console.log('Received message:', message);
});

总结建议

微前端不是银弹。如果你只是为了赶时髦而引入它，很快就会发现维护成本比解决的问题还多。

实施前请自问：

• 应用是否真的大到单团队无法维护？
• 团队是否需要异构技术栈支持？
• 是否有能力处理版本兼容和状态共享的复杂性？

如果答案是否定的，单体应用依然是首选，调试起来更直观。若决定采用微前端，务必做好规划：选择合适的框架，制定清晰的通信机制和样式隔离方案。否则，很容易掉进一个比原来更深的新坑里。