剖析jQuery中isWindow与isPlainObject在跨框架（iframe）判断时的缺陷

jQuery自带的工具函数isWindow和isPlainObject在平时使用中似乎没太大问题，可一旦页面结构变得复杂，比如在页面中嵌入了同源或跨域的iframe，这两个函数的判断结果就可能变得不可靠，甚至直接抛出SecurityError。理解这些缺陷的根源，不仅有助于避开雷区，还能在遇到类似框架隔离场景时写出更健壮的代码。

isWindow的实现逻辑与跨框架隐患

先看jQuery中isWindow的实现。jQuery 3.x的源码里，isWindow函数非常简洁：

isWindow: function( obj ) {
    return obj != null && obj === obj.window;
}

这个判断利用的是一条JavaScript语言特性：浏览器环境中，全局window对象自身有一个window属性，并且严格等于自身。因此在常规的同源页面中，用这个函数判断一个元素是否为window对象足够高效可靠。

然而，在跨域iframe场景下，这段简单的代码会触发访问受限属性。当父页面持有iframe的contentWindow引用时，由于浏览器的同源策略，父页面不能随意读取子窗口内部对象的属性。jQuery的isWindow会执行obj.window，对跨域的contentWindow对象来说，这个属性访问会被浏览器拦截并抛出SecurityError。即使你在try/catch中捕获了异常，函数也无法返回预期的布尔值，而是在抛出异常之前就中断了。

此外，即使是同源iframe，isWindow也可能出现逻辑上的误判。如果某个普通对象上人为挂载了一个window属性并令其指向自身，那么isWindow会把这个对象识别成window。虽然这种情况在真实业务中较少见，但也暴露了该函数只做浅层特征匹配、未进行构造原型核验的设计局限。

isPlainObject在跨iframe场景下的判断失效

isPlainObject用来判断一个对象是否为纯粹的对象字面量，也就是通过Object构造或字面量创建的普通对象。jQuery 1.x和2.x早期的实现中，有一个非常著名的跨框架bug，它的核心逻辑依赖constructor属性：

isPlainObject: function( obj ) {
    if ( jQuery.type( obj ) !== "object" || obj.nodeType || jQuery.isWindow( obj ) ) {
        return false;
    }
    try {
        if ( obj.constructor && !hasOwn.call( obj, "constructor" ) &&
            !hasOwn.call( obj.constructor.prototype, "isPrototypeOf" ) ) {
            return false;
        }
    } catch ( e ) {
        return false;
    }
    return true;
}

在同一个window内，这个逻辑可以正确区分普通对象和自定义构造器对象。可一旦对象来自iframe，比如iframe.contentWindow.Object生成的对象，它的constructor属性指向的是子窗口中的Object函数，这与父窗口的Object函数不是同一个引用。旧版jQuery通过obj.constructor与“当前窗口的Object”做隐式比较，于是会认为这个干净的普通对象不是plainObject。这是跨框架判断失效的最典型原因。

jQuery 3.x已经意识到这个问题，并用toString方法配合Function.prototype.toString比较来规避跨窗口引用不一致的问题。其实现大致如下：

function isPlainObject( obj ) {
    var proto, Ctor;
    if ( !obj || toString.call( obj ) !== "[object Object]" ) {
        return false;
    }
    proto = Object.getPrototypeOf( obj );
    if ( !proto ) {
        return true;
    }
    Ctor = hasOwn.call( proto, "constructor" ) && proto.constructor;
    return typeof Ctor === "function" &&
        fnToString.call( Ctor ) === Function.prototype.toString.call( Object );
}

这个版本通过比较构造函数序列化后的字符串，而不是比较函数引用，所以在同源iframe中依然能够识别出iframe里的普通对象。但这并不代表缺陷被完全消灭。如果iframe与父页面处于完全不同的源，父页面可能连obj本身都无法安全读取，更不用说调用Object.getPrototypeOf了。或者当对象具有自定义Symbol.toStringTag时，toString.call(obj)会返回被修改过的标签，进而影响最终的判断结果。

在实际业务中，最常见的坑是老版本jQuery在用了iframe后，$.isPlainObject(iframe中的对象)返回false，从而导致AJAX参数序列化、深度扩展等内部逻辑无法正确识别对象。例如在使用$.extend(true, target, iframeObj)时，如果iframeObj被识别成“非普通对象”，jQuery会直接将其作为整体赋值，而不会递归合并，造成数据丢失或结构异常。因此这是需要重点防范的兼容性问题。

如何实现跨框架可靠的类型判断

了解了isWindow和isPlainObject的缺陷之后，在设计自己的工具函数时，可以绕开这些不可靠的判断路径。针对isWindow，最安全的做法是使用Object.prototype.toString直接获取内置标签。在浏览器环境下，window对象返回的是"[object Window]"：

function isWindowSafe( obj ) {
    return Object.prototype.toString.call( obj ) === "[object Window]";
}

注意，这个方法不会尝试访问obj.window，因此不会触发跨域异常。不过在部分旧版本IE中，window的toString返回的是"[object Object]"，所以还需要结合typeof obj !== "undefined" && obj !== null && obj.window === obj等安全手段兼容。

对于isPlainObject，我们可以改用一种不依赖具体Object构造函数引用的策略。先使用Object.prototype.toString确保对象的基础类型为"[object Object]"，再通过Object.getPrototypeOf获取原型，判断原型是否直接来自Object.prototype或者原型链路是否为空。因为对象跨窗口时，Object.prototype的引用不同，所以不能直接比较原型引用，可以用原型上constructor序列化后的名称进行辅助判断，或者干脆判断原型对象是否存在constructor属性且constructor上有没有"isPrototypeOf"方法。这里给出一个简化但有效的实现：

function isPlainObjectSafe( obj ) {
    var proto;
    if ( Object.prototype.toString.call( obj ) !== "[object Object]" ) {
        return false;
    }
    proto = Object.getPrototypeOf( obj );
    if ( proto === null ) {
        return true;
    }
    return typeof proto.constructor === "function" &&
        proto.constructor.toString() === Object.prototype.constructor.toString();
}

这个实现的关键在于不直接比较函数引用，而是比较函数的字符串形式。由于原生Object函数的toString结果在所有window中形如"function Object() { [native code] }"，所以可以跨框架匹配。

如果项目还在使用jQuery，并且需要兼容老版本的isPlainObject行为，可以结合jQuery.isWindow的缺陷，在调用前先检测对象是否来自iframe。一个简单的思路是，直接利用Array.isArray和Object.prototype.toString这类不受iframe影响的API替代jQuery的依赖。而在业务代码里，尽量避免把iframe中的对象直接传给jQuery的extend、param等内部函数，必要时对对象做一次序列化或深拷贝再传入。这样能有效避开jQuery类型判断的暗坑，为框架隔离场景提供更稳定的数据传递。

总的来说，jQuery的isWindow和isPlainObject都存在跨框架场景下的设计缺陷。isWindow的安全隐患来自对obj.window的跨域访问，isPlainObject的误判则源于旧版本对constructor引用的强依赖。掌握这些底层实现的边界条件，可以帮助开发者在遇到iframe嵌套时迅速定位问题，并写出更可靠的工具逻辑。

jQueryisPlainObjectiframe修改时间：2026-08-28 19:23:06