微前端需隔离的是全局环境状态和原型链可写性，而非继承机制本身；子应用篡改Array.prototype等会污染其他应用，应通过冻结原型或代理沙箱拦截修改，模块化开发可天然封闭继承关系。
微前端架构下，JavaScript 继承机制本身不直接导致跨应用污染，真正需要隔离的是 全局环境状态 和 原型链的可写性——因为子应用若擅自修改 Array.prototype、Object.prototype 或其他内置构造函数的原型，会影响所有共享同一 JS 执行上下文的其他子应用。这种“原型篡改”属于典型的 JavaScript 隔离失效场景，和传统面向对象语言中的“继承冲突”不同，它不是语法层面的继承问题，而是运行时环境被破坏的问题。
防止原型链被意外篡改
子应用一旦执行类似 Array.prototype.push = customPush 或 String.prototype.myMethod = ... 的代码，主应用和其他子应用调用原生方法时就会出错或行为异常。这不是继承逻辑的问题，而是对共享原型对象的非法写入。
- 主应用应在加载子应用前，对关键原型对象做 冻结（freeze） 或 密封（seal），例如：
Object.freeze(Array.prototype); Object.freeze(Object.prototype); - 更稳妥的做法是使用 代理沙箱（Proxy Sandbox）：在子应用执行前，用
Proxy包裹window及其常见原型对象，拦截所有对prototype的赋值操作，并抛出警告或静默拒绝。 - 避免依赖“修复 constructor”的老式继承写法（如
Child.prototype.constructor = Child），这类操作本身就在修改原型属性，应统一通过class语法或寄生组合继承封装，确保不暴露原型修改逻辑。
子应用内部继承逻辑无需特殊隔离
每个子应用内部定义的类（如 class Button extends Component）或构造函数继承（如 function Sub() { Super.call(this) }）只作用于自身作用域，不会影响其他子应用。JS 的原型链查找始终从当前实例出发，向上仅遍历自己的原型链，不会跨应用“串链”。
- 只要子应用不把自定义类挂到
window上（比如window.MyButton = Button），其继承关系就天然封闭。 - 推荐子应用全部采用模块化（ESM）方式组织代码，避免任何全局变量暴露，继承行为完全在模块作用域内闭环。
- 若子应用必须导出类供主应用调用，应通过明确的 API 接口（如
createApp()工厂函数）返回实例，而非暴露构造函数本身。
沙箱环境切断原型污染路径
主流微前端框架（如 qiankun、Garfish）默认启用沙箱机制，其中“代理沙箱”能有效拦截对全局对象及其原型的修改。它不是阻止继承，而是让子应用看到的 window 是一个代理对象，所有读写操作都受控。
- 当子应用尝试执行
Array.prototype.custom = fn，代理可捕获该操作并拒绝，同时不影响子应用自身对Array实例的正常使用。 - 沙箱还会重置子应用卸载后的副作用，包括已注入的原型方法，确保下次加载干净重启。
- 注意：Iframe 沙箱虽物理隔离最彻底，但无法共享 DOM 和通信开销大，一般仅用于高危子应用；日常推荐代理沙箱 + 原型冻结双保险。
本质上，微前端要隔离的不是“继承语法”，而是“对共享原型的写权限”。控制住这个入口，各子应用内部怎么用 extends、怎么写 call 继承，都不构成风险。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
