商协会后台前端的模块聚合实践

商协会后台功能多：会员、会费、活动、报表、供需，每个模块独立迭代，又要在同一个后台里出现。微前端是聚合它们的务实方案。

为什么用微前端

单体前端改一个模块要全量构建，模块多了互相拖累。微前端让会员、会费、活动各自独立开发部署，主框架用 qiankun 统一加载，互不污染。

主应用装配

js 复制代码

import { registerMicroApps, start } from 'qiankun';
registerMicroApps([
  { name: 'member', entry: '//member.xxx.com', container: '#subapp', activeRule: '/member' },
  { name: 'fee', entry: '//fee.xxx.com', container: '#subapp', activeRule: '/fee' },
]);
start();

子应用按 activeRule 懒加载，进哪个菜单拉哪个，首屏不卡。

样式与状态隔离

qiankun 默认沙箱隔离样式，避免 CSS 互冲。跨模块状态用主应用 EventBus 或共享 store，别直接调对方内部。

权限按模块下發

主框架拿到用户角色，按路由下发各子应用的可见菜单。会员模块财务看不见，会费模块秘书能进，粒度到按钮。

我们这边在用的未来漫城商协互联平台，后台就是微前端聚合的，新增一个供需模块不用动其它代码，独立发版。商会需求变，模块加得快，交付才跟得上。

微前端不是银弹，小系统用不着。但商协会后台模块多、各自迭代，它是牢靠的聚合方式------独立开发、统一呈现、互不影响。沙箱隔离原理

qiankun 用 Proxy 沙箱隔离全局变量，js 沙箱 + 样式沙箱双保险。子应用改 window 不影响主应用，CSS 加前缀不互冲。多个子应用并存也不打架。

部署与踩坑

子应用得配跨域头，主应用才能拉。路由用 history 模式要配基座 fallback。子应用独立构建，别打进主包，否则失去微前端意义。

性能优化

只加载当前激活子应用，其余懒加载。公共依赖（Vue、组件库）抽到基座共享，子应用瘦身。首屏只拉主框架+默认子应用，快。

后台微前端聚合后，加模块不影响已有功能，独立发版。商会模块多、变起来快，这架构扛造。

微前端适合模块多、各自迭代的中后台。小系统上它反而重，按需取用。适用边界

模块少于三个、迭代不同步，别上微前端，单体更省事。模块多、各自发版节奏不一、要独立技术栈，才是微前场的场景。商协会后台模块多、变起来快，正合适。

沙箱和懒加载配好，首屏不卡、互不打架，秘书处用着顺。架构选对，交付才轻。微前端的代价

沙箱和懒加载有性能开销，首屏多一层加载。模块少时这开销不值。等模块上五个、各自发版，聚合的收益才盖过代价。

选型看规模。商协会后台模块多、变起来快，微前端正合适；小系统用单体，别为了架构而架构。

落地后，加模块不影响已有功能，独立发版，商会需求变，技术跟得上。模块多、变起来快，微前端正合适。