在严格模式下，object.setprototypeof() 修改不可扩展、密封或冻结对象的原型会抛出 typeerror；应通过 object.isextensible/issealed/isfrozen 检测并避免修改，优先使用 object.create 或组合替代继承。
在严格模式下，尝试用 Object.setPrototypeOf() 修改不可扩展、密封或冻结对象的原型，会直接抛出 TypeError。这不是 bug，而是 JavaScript 主动暴露问题的设计——把原本静默失败的操作变成可捕获、可干预的错误。
先确认对象是否已被锁定
原型修改失败，往往是因为对象本身已被限制扩展。可用三个内置方法快速检测：
-
Object.isExtensible(obj)：返回
false表示对象不可扩展，setPrototypeOf必然失败 - Object.isSealed(obj)：密封对象同样禁止原型变更（即使属性仍可读写）
- Object.isFrozen(obj)：冻结对象最严格，原型和所有属性均不可改
只要其中任一返回 true，就说明该对象的原型链已被锁定，不应再尝试替换。
避免后期修改，从创建阶段就设定原型
真正安全的做法不是“兜底处理异常”，而是避开触发条件。推荐两种初始化方式：
- 用
Object.create(proto, descriptors)创建对象，直接指定原型，无需后续修改 - 若需动态行为，改用组合而非继承：把逻辑抽成独立函数或 class 实例，通过属性挂载或参数传入，不依赖
__proto__切换
尤其注意：不要对 DOM 元素、React 组件实例、Promise 对象等第三方返回值调用 setPrototypeOf，它们多数由引擎内部设为不可扩展。
仅限兼容性试探时捕获异常
如果必须做环境能力检测（比如 polyfill 判断浏览器是否支持某原型特性），可用 try/catch，但不能用于主流程逻辑：
function supportsProtoSwap() {
const test = {};
try {
Object.setPrototypeOf(test, {});
return true;
} catch {
return false;
}
}
捕获后应降级使用替代方案（如属性代理、方法委托），而不是重试或忽略错误。
检查是否误启用了严格模式
有时异常看似突兀，其实是代码顶部有 "use strict" 或模块默认启用严格模式（ES6 模块自动严格）。非严格模式下，setPrototypeOf 对不可扩展对象会静默失败；而严格模式强制报错。若业务确实需要宽松行为且可控，可局部关闭严格模式（不推荐），更稳妥的是重构逻辑，绕过原型修改。
