instanceof跨iframe失效本质是构造函数隔离，因不同全局环境的同名类（如MyClass）内存地址不同，原型链无法匹配；应改用Object.prototype.toString.call()等跨环境安全方案。
跨 iframe 继承导致的 instanceof 失效，本质不是“继承”出了问题，而是根本不存在跨 iframe 的继承关系——因为两个环境中的构造函数（包括父类、子类）彼此隔离、互不相识。
看构造函数是否来自同一全局环境
这是最直接的判断依据。如果对象是在 iframe 中创建的，而你在主窗口用 obj instanceof MyClass 判断，先确认 MyClass 是否真的存在于主窗口作用域中：
-
主窗口没有定义该类：iframe 里写的
class A {}，主窗口访问不到，typeof MyClass === 'undefined'，自然报错或返回false -
同名但不同引用：即使主窗口和 iframe 都定义了
class A {}，iframe.contentWindow.A === A仍为false，它们是两个完全独立的函数对象 -
检查实例的 constructor：
obj.constructor === iframe.contentWindow.MyClass才可能为true；若写成obj.constructor === MyClass，基本为false
验证原型链是否连得上目标 prototype
instanceof 内部比对的是原型链上是否存在右侧构造函数的 prototype。可手动模拟这个过程：
- 打印
obj.__proto__，再往上查obj.__proto__.__proto__，直到为null - 分别获取两个环境下的目标 prototype：
main.A.prototype和iframe.contentWindow.A.prototype - 用
===比较它们——只要任一环节不相等，instanceof就必然失败
观察 instanceof 行为是否“意外为 false”
以下现象高度提示跨 iframe 失效，而非代码逻辑错误：
-
Array.isArray(obj)返回true，但obj instanceof Array却是false -
obj instanceof iframe.contentWindow.MyClass为true，但换成本窗口同名类就为false -
Object.prototype.toString.call(obj)显示[object MyClass]（说明类型信息还在），但instanceof不认 - 在 iframe 内部执行判断一切正常，一回到父级上下文就失效
避免误判：区分“继承失效”和“根本无继承”
真正的继承（如 class B extends A）只在单个执行上下文中有效。跨 iframe 时：
- 不存在
iframe.A.prototype === main.A.prototype这种共享 - 更不存在
iframe.B.prototype.__proto__ === main.A.prototype这样的跨环境原型链接 - 所谓“跨 iframe 继承”，实际是开发者误以为类结构能穿透沙箱——它不能
