jQuery的load()方法经常被用来从服务端获取HTML片段并注入到指定容器中，用法看似简单：$('#result').load('/partial.html')。但很多开发者在使用时忽略了返回内容中如果带有<script>标签，这些脚本并不会像浏览器正常解析HTML时那样执行，而是被jQuery单独提取出来后手动触发。这种机制一方面方便了动态加载后立刻运行初始化逻辑，另一方面也带来了重复执行、作用域污染以及潜在的XSS风险。要理解这些问题，必须从load()内部如何处理返回的HTML说起。
load()对返回HTML的处理流程与脚本执行条件
load()本质上是对$.ajax()的封装。当请求成功后，jQuery会将返回的HTML字符串交给自身实例的html()方法处理。html()方法在设置内容时，并不会简单调用浏览器原生innerHTML，而是进入了jQuery的domManip函数。domManip首先利用buildFragment对HTML字符串进行解析，创建一个文档片段。在解析过程中，所有的<script>元素会被识别并单独收集到一个数组里，剩余的非脚本节点则被插入目标容器。
接下来jQuery遍历收集到的脚本节点。对于没有src属性的内联脚本，它会取出脚本的文本内容，通过jQuery.globalEval函数在全局作用域中执行。对于带有src属性的外部脚本，jQuery会使用ajax再次发起异步请求将其拉取并执行。关键点在于：内联脚本的执行发生在DOM元素已经插入目标容器之后，但外部脚本由于是异步加载，其执行时间点无法保证，且脚本之间的顺序可能会被打乱。
下面的例子展示了load()加载一个包含内联脚本的HTML片段。假设服务端返回内容如下：
<div>这是加载的部分内容</div>
<script>
console.log('片段中的内联脚本执行了');
window.loadedFromPartial = true;
</script>
前端调用代码：
$('#result').load('/api/partial', function() {
console.log('load完成回调执行');
console.log(window.loadedFromPartial); // 通常输出 true
});
从输出结果可以看到，内联脚本在load完成回调触发之前就已经执行完毕，并且声明的window.loadedFromPartial已经变成了true。这说明脚本是在DOM插入后、回调执行前被同步执行的。如果脚本中使用了let或const声明块级变量，由于jQuery.globalEval采用间接eval的方式，这些变量不会成为window的属性，但var声明的变量则会污染全局作用域。
脚本执行顺序与重复执行陷阱
当返回的HTML片段中包含多个<script>标签时，执行顺序会变得复杂。对于连续的内联脚本，jQuery会按照它们在HTML中出现的顺序依次同步执行，因此后面的脚本可以访问前面脚本定义的全局变量。然而一旦混入带src的外部脚本，问题就出现了。外部脚本通过异步ajax加载，其完成时间取决于网络状况，所以即使它在第一个内联脚本之前声明，也可能在后一个内联脚本之后才执行。这会导致依赖关系错乱，比如外部脚本定义了一个全局函数，但紧随其后的内联脚本尝试调用该函数时，函数尚未加载完成。
另一个容易被忽视的问题是重复执行。每次调用load()或html()设置新的内容时，jQuery都会重新解析并提取其中的script标签。如果同一个片段被加载两次，脚本也会被执行两次。下面的代码演示了这种重复执行带来的副作用：
// 服务端返回片段：
// <script>window.partialCount = (window.partialCount || 0) + 1;</script>
$('#result').load('/api/count-fragment');
$('#result').load('/api/count-fragment');
// 最终 window.partialCount 的值为 2，而不是 1
这种重复执行在某些场景下可能只是产生冗余的全局变量或重复绑定事件，但在更复杂的情况下会导致内存泄漏、多次初始化组件甚至业务逻辑错乱。例如一个脚本负责给容器中的按钮绑定click事件，如果片段被加载两次，同一个按钮就会绑定两个完全相同的处理函数，用户点击一次会触发两次逻辑。
此外，load()执行内联脚本的方式与浏览器原生解析存在差异。原生解析中，内联脚本会在文档解析到该位置时立即执行，并且此时脚本前面的DOM元素已经存在，后面的DOM元素尚未创建。而jQuery的做法是先将所有非脚本节点一次性插入目标容器，然后再统一执行脚本。因此脚本执行时，整个片段的所有DOM节点都已经可用。这个差异在某些依赖DOM顺序的场景下可能造成行为不一致，开发者不应假设脚本执行时后续节点尚未构建。
安全风险来源与XSS防御建议
从安全角度看，load()最大的危险在于它允许返回内容中的脚本自动在页面上下文中执行。如果加载的HTML片段来自用户输入、第三方广告接口或不可信的数据源，攻击者就可以在script标签中植入任意JavaScript代码。一旦load()被调用，这些恶意代码就会像正常脚本一样运行，从而窃取用户Cookie、劫持页面操作或发起伪造请求。即便服务端返回的内容本身没有脚本，攻击者也可能通过注入<img onerror=...>等事件属性来触发代码，而jQuery在插入这些HTML时，部分事件属性可能会被浏览器直接执行。
跨域限制并不能完全阻隔风险。load()默认受同源策略约束，但如果目标服务器配置了宽松的CORS头，允许当前源读取响应内容，那么跨域加载的HTML片段同样会被解析并执行其中的脚本。更值得警惕的是，某些jQuery版本在处理外部script标签时可能使用动态创建<script>节点的方式加载，这种方式在某些浏览器中能够绕过部分CSP对eval的限制，从而扩大攻击面。
要规避这些风险，首先应避免使用load()去加载任何包含用户可控内容或不受信任来源的HTML。如果业务上确实需要动态展示服务端返回的富文本，可以考虑使用更安全的方案：用fetch或$.ajax获取纯文本，先经过DOMPurify等库进行净化，移除所有script标签和危险的事件属性，然后再通过html()插入。但需要注意，即便净化后，jQuery的html()方法仍然会尝试执行残留的script标签，因此净化必须保证彻底移除所有script节点。
// 不推荐的写法：直接加载用户可控URL
$('#content').load('/search?q=' + encodeURIComponent(userInput));
// 推荐的安全写法：获取文本后净化，再手动插入
$.get('/api/result')
.done(function(data) {
var clean = DOMPurify.sanitize(data, {
SAFE_FOR_JQUERY: true,
FORBID_TAGS: ['script', 'style']
});
$('#content').html(clean);
});
另一种更严格的方案是彻底放弃让浏览器解析HTML，改用textContent将返回内容作为纯文本展示，这样可以从根源上杜绝脚本执行。如果必须展示有限的HTML结构，可以在服务端使用白名单过滤，只允许特定的安全标签和属性通过。同时建议在服务端响应头中设置Content-Security-Policy，禁止内联脚本和eval，进一步降低XSS攻击成功后的影响范围。对于不再需要支持老式浏览器的项目，可以完全弃用jQuery的load()，改用原生fetch配合DOM API手动构建元素，从而对脚本执行拥有完全控制权。
总之，load()加载HTML片段时的脚本执行机制是一把双刃剑。它简化了局部刷新后初始化逻辑的编写，但也将脚本执行的控制权部分交给了不可控的返回内容。理解其内部流程、执行顺序和安全边界，才能在实际项目中做出更稳健的技术选择。
jQuery load方法HTML片段加载脚本执行安全修改时间：2026-08-28 16:33:48