微前端中不存在“公共基类状态”概念，因框架不支持跨应用类继承，运行时隔离导致原型链断裂、模块实例独立；应采用状态代理层、全局事件订阅或按域划分所有权等显式通信方式实现安全共享。
微前端中不存在“公共基类状态”这一原生概念——React、Vue 等框架本身不提供跨应用的类继承链，更不支持子应用通过继承主应用某个基类来共享状态。所谓“组合寄生继承”是面向对象编程（如 C#、Java）中的设计模式，用于模拟多重继承或增强复用性，但它在浏览器运行时的微前端场景中无法直接落地。
为什么不能靠“继承”隔离或共享状态
微前端的核心特征是运行时隔离：每个子应用拥有独立的 JavaScript 执行上下文、独立的模块作用域、独立的 React/Vue 实例树。即使主应用导出一个 class BaseState，子应用也无法真正“继承”它并获得其运行时实例状态，原因包括：
- 不同子应用打包后运行在各自
iframe或沙箱（如 qiankun）中，instanceof失效，原型链断裂 - ES 模块的
import是静态链接，不传递运行时对象引用；两次import同一模块，得到的是两个独立模块实例 - 寄生继承依赖构造函数调用与原型赋值（如
Child.prototype = Object.create(Parent.prototype)），但在跨应用边界时，Parent 的 prototype 不可跨沙箱访问
真正可行的“状态隔离 + 共享”替代方案
应放弃“继承”思路，转向基于契约和通信的显式状态管理方式：
-
主应用统一初始化 + 子应用只读订阅：主应用使用
qiankun.initGlobalState()或自建事件总线（CustomEvent）发布用户、权限、主题等基础状态；子应用通过onGlobalStateChange或window.addEventListener监听，仅消费不修改 -
状态代理层封装（推荐）：主应用暴露一个轻量 SDK（如
@mf/shared-state），内部封装对全局状态的读写逻辑与校验规则。子应用导入该 SDK，调用useUser()或getState('theme')，SDK 负责桥接底层通信机制，对子应用屏蔽实现细节 -
按域划分状态所有权：购物车归订单子应用管，用户信息归主应用管，通知中心归独立微服务管。各子应用只维护自己负责的状态，通过标准化接口（如
postMessage或中央 API）触发跨域变更，避免“基类状态”这种模糊归属
若坚持使用类抽象，可这样安全封装
可在主应用中定义一个状态管理类（非基类，而是单例工具），并通过 props 或全局变量透出其实例：
前端设计优化skill
下载
前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。
立即学习“前端免费学习笔记（深入）”；
示例（主应用）：class AppState {
constructor() {
this.user = null;
this.theme = 'light';
}
setUser(user) { this.user = user; }
getTheme() { return this.theme; }
}
// 创建唯一实例，挂载到 window 或通过 initGlobalState 透出
window.__MF_APP_STATE__ = new AppState();
子应用不继承它，而是安全地读取：
示例（子应用）：const appState = window.__MF_APP_STATE__;
if (appState && typeof appState.getTheme === 'function') {
console.log('当前主题：', appState.getTheme());
}
这种方式本质是“共享实例引用”，不是继承，但能达成类似效果，且不破坏隔离原则。
