在IE9中，如果一段代码使用jQuery.ajax的async参数并显式设置为false，请求会以同步方式执行。表面上看，代码执行顺序变得直观，函数返回时数据已经拿到，但实际上浏览器主线程被完全占住，等待服务器响应期间页面无法响应用户操作，控制台还会出现关于同步XMLHttpRequest的警告。这个问题在较旧的浏览器中尤其突出，因为IE9的JavaScript引擎和渲染管线对长时间占用主线程的操作几乎没有保护措施。
下面从现象定位、异步改造和工程化处理三个层面，分析如何在不影响原有业务逻辑的前提下，移除同步Ajax请求并消除警告。
一、同步Ajax为什么会让IE9失去响应
jQuery的ajax方法底层调用的是浏览器提供的XMLHttpRequest对象。当async属性为false时，send方法会同步执行：脚本会停在send这一行，直到服务器返回完整响应或请求超时。在这段时间里，浏览器主线程无法处理其他任务，包括重绘页面、响应点击、执行定时器等。IE9的渲染引擎与脚本执行共用主线程，因此一个耗时500毫秒的同步请求就会让页面冻结500毫秒。
控制台警告通常来自浏览器的开发者工具，检测到主线程上的同步XHR调用后会输出类似Synchronous XMLHttpRequest on the main thread is deprecated的提示。虽然这一警告在不同浏览器中措辞有差异，但指向的问题一致：同步阻塞会严重降低用户体验，甚至让用户误以为浏览器崩溃。IE9是较老的浏览器，没有Web Worker可供转移请求，所以直接在代码中禁用同步请求是最直接的解决办法。
需要注意的是，jQuery中如果省略async参数，默认是异步请求。一些早期代码为了图省事，把async设置为false，然后紧接着使用返回数据。这种写法在本地环境或请求极快时可能没什么感觉，但一旦网络抖动或服务器处理变慢，页面就会明显卡顿。
二、把同步请求改造成异步回调链
消除同步阻塞的第一步，是找出所有依赖同步返回值的代码位置。典型的同步写法如下：
// 原来的同步写法
function getUserInfo() {
var result;
$.ajax({
url: '/api/user',
async: false,
success: function(data) {
result = data;
}
});
return result;
}
var userInfo = getUserInfo();
console.log(userInfo.name);
这种写法中，getUserInfo函数希望直接返回数据，调用方再用返回值继续处理。改成异步后，函数不能直接返回结果，需要接收一个回调函数，把数据通过回调传给后续逻辑。
// 异步回调写法
function getUserInfo(callback) {
$.ajax({
url: '/api/user',
async: true,
success: function(data) {
callback(data);
},
error: function(xhr, status, error) {
callback(null);
}
});
}
getUserInfo(function(userInfo) {
if (userInfo) {
console.log(userInfo.name);
}
});
上面的改动虽然不大，但会把程序的执行流从线性变成嵌套。当有多个顺序依赖的请求时，回调层层嵌套会让代码变得难以阅读。此时可以借助jQuery的Deferred对象来管理异步流程。
Deferred是jQuery从1.5版本开始提供的异步编程工具，可以理解为一个可观察的任务状态容器。ajax方法本身返回一个jqXHR对象，它也实现了Promise接口，因此可以直接使用done、fail、then等方法。把同步请求改成链式调用，既能避免回调地狱，又能保持代码顺序可读。
三、用jQuery Deferred重构多请求依赖
假设业务场景中需要先获取用户信息，再根据用户ID获取订单列表，最后渲染页面。原来的同步写法会让三个请求依次阻塞主线程。使用Deferred后，可以这样改写：
function getUserInfo() {
return $.ajax({
url: '/api/user',
async: true
});
}
function getOrders(userId) {
return $.ajax({
url: '/api/orders',
data: { userId: userId },
async: true
});
}
$.when(getUserInfo())
.then(function(userData) {
return getOrders(userData.id);
})
.then(function(orders) {
renderOrders(orders);
})
.fail(function() {
showError();
});
这段代码中，getUserInfo和getOrders两个函数都直接返回ajax对象，不需要额外的回调参数。$.when可以等待一个或多个异步操作完成，then中的返回值会传递给下一个then。这样既消除了同步阻塞，又保持了业务流程的线性表达。对于IE9，jQuery 1.9及以上版本对Deferred的兼容性良好，不需要额外引入Promise polyfill。
如果项目仍然使用较早版本的jQuery，或者代码中混用了大量回调风格，也可以手动创建一个Deferred对象来包装旧接口。例如下面的代码把原来的回调式函数转换成返回Promise的形式：
function loadConfig() {
var deferred = $.Deferred();
$.ajax({
url: '/api/config',
async: true,
success: function(data) {
deferred.resolve(data);
},
error: function() {
deferred.reject('load config failed');
}
});
return deferred.promise();
}
loadConfig().then(function(config) {
init(config);
});
这种写法虽然比直接返回ajax对象多了几行，但好处是兼容所有旧接口。如果请求成功后还需要对数据做处理再交给后续逻辑，deferred.resolve可以在处理完成后调用，控制更灵活。
四、无法完全异步时的替代思路
个别场景下，开发者可能坚持认为必须拿到数据后才能继续执行，例如页面初始化时多个模块互相关联，改成异步会牵动整体架构。即便这样，也不应保留同步Ajax。可以考虑通过服务端接口合并来减少请求数量，把原本需要串行调用多个接口的逻辑，改成一次性由后端聚合返回。这样前端只需要一个异步请求，初始化流程反而更简单。
另一种思路是使用请求队列加上界面遮罩。异步请求开始前显示加载状态，请求完成后更新界面。这与同步阻塞的区别在于页面仍然能响应用户操作，比如允许用户取消加载或看到明确的进度提示。虽然体验不如完全非阻塞，但至少不会让浏览器假死，也不会触发IE9的同步XHR警告。
对于确实需要按顺序执行的多个任务，可以把它们放进数组，用递归或reduce依次触发。下面的代码展示了如何用数组队列串行执行多个异步请求，前一个成功后再启动下一个：
var tasks = [
function() { return $.ajax({ url: '/api/step1', async: true }); },
function() { return $.ajax({ url: '/api/step2', async: true }); },
function() { return $.ajax({ url: '/api/step3', async: true }); }
];
function runQueue(index, results) {
if (index >= tasks.length) {
console.log('all done', results);
return;
}
tasks[index]().then(function(data) {
results.push(data);
runQueue(index + 1, results);
});
}
runQueue(0, []);
这段代码把同步串行逻辑转成了受控的异步队列，每次只有一个请求在执行。相比手动嵌套回调，队列方式更容易扩展，也能在任意步骤中插入错误处理或重试逻辑。对IE9来说，这种写法只依赖基础的Promise能力，jQuery 1.9以上都能运行。
最后需要强调，移除async:false并不能通过简单的参数替换完成，必须检查调用链中所有依赖同步返回值的代码。建议先在开发环境中打开IE9的开发者工具，复现同步请求，根据警告定位到具体文件与行号，然后逐处修改。修改完成后，在慢速网络条件下测试页面交互，确认用户点击、输入、滚动等操作不再出现明显卡顿。
jQuery Ajax同步模式UI线程阻塞修改时间：2026-09-23 03:05:53