单体前端转向模块化集群需分阶段解耦：先按业务域划界（如“订单中心”），再用微前端框架隔离运行时，统一接入协议与生命周期，渐进替换并解耦状态依赖。
单体前端应用转向模块化集群，不是一次性重写，而是分阶段解耦、渐进式迁移。核心思路是：先隔离边界、再定义契约、最后按需加载，让新老代码共存，团队可并行开发。
按业务域划分模块边界
从用户视角识别稳定的功能单元，比如“订单中心”“支付网关”“用户资料页”，每个单元封装完整逻辑（UI + API + 状态），不跨域共享变量或 DOM。避免按技术分层（如“所有组件放一起”），而要按业务闭环切分。一个模块应能独立运行、测试和部署。
- 用微前端框架（如 qiankun、Module Federation）做运行时沙箱，隔离 JS 执行环境与样式作用域
- 主应用只保留路由调度和公共布局，其余页面由子应用动态挂载
- 模块间通信走标准化事件总线或 props 透传，禁止直接调用对方内部函数
统一模块接入协议
所有子模块必须实现约定的生命周期钩子（bootstrap/mount/unmount），并导出符合规范的入口。例如：
- 导出 render 函数，接收容器节点和配置，负责初始化 UI
- 导出 getInitialState，提供默认状态供主应用协调
- 暴露 actions 对象，声明可被外部触发的能力（如“刷新订单列表”）
这样主应用无需关心子模块用 React 还是 Vue，只要接口一致就能集成。
立即学习“Java免费学习笔记（深入）”；
渐进式替换与流量灰度
不追求“一刀切”。初期把非核心页面（如帮助中心、关于我们）抽为子应用；中期将高频但低耦合模块（如地址管理、优惠券选择器）拆出复用；最后攻坚主流程（如下单页），用 A/B 测试对比性能与稳定性。
- 通过 URL 路径匹配决定加载哪个子应用，便于回滚
- 构建时生成独立 bundle，支持单独发版、独立监控错误率与加载耗时
- 主应用保留降级逻辑：子应用加载失败时显示静态 fallback 或跳转旧页面
依赖与状态的解耦策略
模块之间不共享 Redux store 或 Pinia 实例。每个子应用维护自身状态，跨模块数据流动靠显式传递：
- 主应用通过 props 向子应用注入用户信息、权限码等上下文
- 子应用通过自定义事件通知主应用关键动作（如“用户已登录”“订单已提交”）
- 全局配置、国际化资源、主题色等基础能力，以独立 npm 包形式发布，各模块按需引入
避免循环依赖的关键是：只允许子应用依赖主应用提供的基础能力，不允许反向依赖。
