不同浏览器原型继承兼容性总体稳定，但ie9–10和android 4.4以下webview存在object.create缺陷，需退至寄生组合式继承；现代浏览器全面支持class/extends和object.setprototypeof；应避免原型污染误用，精准polyfill关键场景。
不同浏览器下原型继承的兼容性总体稳定，但关键差异集中在老旧引擎对标准语法的支持程度和运行时行为一致性上。IE9–10、旧版安卓 WebView（尤其4.4以下）仍是主要风险区；现代浏览器（Chrome 60+、Firefox 55+、Safari 12+、Edge 79+）对 class/extends 和 Object.setPrototypeOf 均已完整支持，基本无兼容顾虑。
底层继承必须考虑引擎缺陷
IE9–10 和部分 Android 4.x WebView 中，Object.create(Parent.prototype) 可能触发原型污染或返回 null，导致继承链断裂。这不是语法不支持，而是引擎实现未严格遵循 ES5 规范。此时应退回到经典寄生组合式继承：
- 用空构造函数
function F() {}作中转 -
F.prototype = Parent.prototype -
Child.prototype = new F() - 手动修正
constructor指向
全程避开Parent构造函数调用，也避免属性拷贝，只建立干净的原型链链接。
class 语法在现代环境里是安全且高效的class A extends B 不是“替代”原型，而是对寄生组合式继承的标准化封装。Babel 和 TypeScript 编译器会将其可靠转译为高性能 ES5 代码；V8、SpiderMonkey、JavaScriptCore 等引擎均做了针对性优化（如原型访问内联缓存）。只要目标环境明确（如 browserslist: "> 0.5%, not dead"），就可放心使用，无需手写兼容逻辑。
运行时 polyfill 要精准，不能全局污染
对 Object.setPrototypeOf 或 Reflect.setPrototypeOf 的缺失，不应直接覆盖原生方法，而应在检测到不支持时，仅对关键基类（如自定义 EventEmitter、Store 类）做轻量补丁。例如：
- 先
if (!Object.setPrototypeOf) { ... }检测 - 补丁只作用于需动态修改原型的极少数场景
- 现代环境完全跳过，不增加任何开销
真正影响兼容性的不是继承写法，而是误用模式
- ❌
Object.assign(Child.prototype, Parent.prototype)—— 扁平化方法，切断原型链，失去动态更新能力 - ❌ 在原型上直接挂数组/对象（如
Child.prototype.items = []）—— 实例间共享引用，引发状态污染 - ✅ 构造函数内初始化可变数据（
this.items = []） - ✅ 接口契约优先：用 TypeScript
implements或 duck-typing 明确行为约定，降低继承深度，让“组合优于继承”可落地
不复杂但容易忽略
