globalEval是jQuery源码中一个容易被忽视但极其精巧的函数，它位于jQuery的核心模块中，代码不过二十来行，却解决了前端开发里一个经典难题：如何让一段动态获取的脚本字符串在全局作用域下执行。普通的eval调用受限于调用时的词法作用域，声明的变量只会留在局部，而动态插入DOM的script标签按规范必须在全局环境运行，jQuery正是借助globalEval抹平了这两者之间的鸿沟。本文将从作用域原理、源码实现和严格模式的冲突三个层面，把这段经典代码彻底讲透。
一、为什么需要globalEval：eval的词法作用域陷阱
要理解globalEval的存在意义，先得明白原生eval的一个关键特性：eval会在调用者所在的词法作用域中执行代码。也就是说，你在函数里调用eval，里面声明的变量就只属于这个函数，外部完全访问不到。举个例子，假设我们在一个闭包中执行eval("var a = 1;")，那么变量a只存在于这个闭包里，闭包执行完毕后a也随之消失，全局环境中根本找不到这个变量。
但在实际开发中，很多场景要求脚本必须在全局生效。最典型的就是DOM操作：通过html()方法插入一段包含<script>标签的HTML时，浏览器对真实script标签的处理是将其放入全局作用域执行的。jQuery内部为了避免直接操作DOM带来的性能问题，往往先把脚本内容提取成文本，再统一执行，这时候如果简单粗暴地调用eval，脚本里声明的全局变量和函数就全部变成了局部变量，脚本等于白执行了。
看一个直观的对比：
function broken() {
eval("var appName = 'demo';");
// appName 只存在于 broken 内部
}
broken();
console.log(typeof appName); // undefined
function fixed() {
// 间接调用 window.eval，在全局作用域执行
(0, eval)("var appName = 'demo';");
}
fixed();
console.log(typeof appName); // string上面代码中的(0, eval)写法就是所谓的间接eval调用。JavaScript规范规定，当eval不是被直接以标识符形式调用，而是通过表达式求值后再调用时，它就脱离了当前的词法环境，改为在全局作用域中执行。jQuery的globalEval本质上就是对这一技巧的封装和兼容性增强。
二、源码拆解：globalEval如何跨浏览器实现全局执行
翻开jQuery的源码，globalEval的实现大致分为两个时代。早期的实现采用脚本注入方案，代码思路如下：
globalEval: function( code ) {
if ( code && jQuery.trim( code ) ) {
// 尝试利用 window.execScript，IE 专属的全局执行接口
if ( window.execScript ) {
window.execScript( code );
} else {
// 其他浏览器：创建一个 script 标签插入 document.head
var script = document.createElement( "script" );
script.text = code;
document.head.appendChild( script ).parentNode.removeChild( script );
}
}
}这段代码有三个值得注意的细节。第一是优先使用window.execScript，这是老版本IE提供的接口，天然在全局作用域执行脚本，性能也不错。第二是标准浏览器走script标签注入路径，把代码塞进临时创建的<script>元素，插入DOM后浏览器会立即执行其中的代码，执行完马上移除节点，干净利落。第三是无论哪条路径，都没有依赖eval，这避免了某些严格模式场景下的限制。
后来浏览器引擎普遍支持了间接eval调用，jQuery在新版本中把实现简化为更优雅的形式：
var isFunction = function( obj ) {
return typeof obj === "function";
};
// 检测间接 eval 是否在全局作用域执行
var testGlobalEval = function() {
var result = false;
try {
// 严格模式下用 var 声明不会泄漏到全局，改用赋值给未声明变量
( 0, eval )( "var globalEvalTest = 1;" );
result = ( window.globalEvalTest === 1 );
} catch ( e ) {}
return result;
};
// jQuery 3.x 简化后的实现思路
function globalEval( code, options, doc ) {
// 省略部分上下文处理逻辑
( 0, eval )( code );
}这里的(0, eval)逗号表达式是核心。逗号运算符会先求值0，再返回eval的引用，此时调用eval时它已经不是直接调用形式，引擎判定这是一次间接调用，于是切换到全局执行环境。这种写法相比脚本注入的好处是不需要接触DOM，在非浏览器环境（比如某些支持DOM的jsdom场景之外的工具链）中也能工作。
三、严格模式下的限制：声明不泄漏与NO_GLOBAL_EVAL警告
严格模式给globalEval带来了第一个麻烦：在严格模式下，eval有自己的词法环境，通过var声明的变量和函数不会泄漏到外层作用域。即使你使用间接调用让代码在全局执行，如果被执行的代码字符串本身以严格模式指令开头，或者整个脚本处于严格模式上下文，声明依然被封在eval创建的独立作用域里。
看下面这个例子：
// 被执行的代码自带严格模式 ( 0, eval )( '"use strict"; var strictVar = 1;' ); console.log( typeof window.strictVar ); // undefined // 不带严格模式的代码，var 会泄漏到全局 ( 0, eval )( 'var normalVar = 2;' ); console.log( typeof window.normalVar ); // number
所以jQuery在使用globalEval执行脚本前，会做一步脚本清洗：移除代码开头的严格模式声明，确保动态脚本中的var和函数声明能够顺利挂到全局对象上。这一步在源码里体现为对"use strict"字符串的检测与剔除，虽然看起来有点取巧，却是保证动态脚本行为与传统script标签一致的关键处理。
第二个限制来自构建工具和现代运行环境。一些打包器和运行时会对eval的使用发出警告，例如某些框架的开发模式会提示NO_GLOBAL_EVAL，意思是检测到globalEval在这种环境下不可用或行为不可靠。原因在于部分沙箱环境、Content Security Policy严格策略下，eval类接口会被直接禁用，调用会抛出安全错误。jQuery对此的处理是：一旦探测到全局eval能力不可用，相关DOM操作仍会执行，只是其中的脚本内容会被跳过，并在控制台给出警告。
四、实践建议：如何正确使用与替代globalEval
在日常开发中，直接调用globalEval的场景不多，但理解它的原理能帮你排查不少诡异问题。比如动态插入HTML后脚本不执行、变量未定义等，多半和执行上下文以及严格模式有关。如果你自己需要实现类似功能，建议遵循以下几点：
- 优先考虑script标签注入方案，把代码写入
<script>元素再插入DOM，行为最接近浏览器原生处理方式，对CSP也更友好（配合nonce或白名单）。 - 如果必须用eval，务必使用间接调用形式
(0, eval)，并清楚它无法突破严格模式的声明隔离。 - 被eval的代码中要创建全局变量时，避免依赖
var泄漏，改用window.xxx = ...显式赋值，这在任何模式下都可靠。 - 在启用Content Security Policy的项目中，预先评估
unsafe-eval策略的取舍，或干脆把动态逻辑改成JSON数据加本地函数映射的方案，彻底摆脱运行时代码求值。
最后值得一提的是，随着前端工程化和安全要求的提升，运行时执行动态字符串代码的做法正在被边缘化，现代框架更倾向于声明式渲染和预编译。但globalEval作为jQuery时代处理动态脚本的最佳实践，其背后对作用域机制、浏览器差异和严格模式的深入理解，至今仍是衡量JavaScript基本功的绝佳素材。读懂这二十行代码，你对JavaScript执行上下文的理解会上一个台阶。
jQuery globalEval严格模式执行上下文修改时间：2026-09-01 18:06:43