Ajax异步执行顺序错乱：从原理到Promise、async/await实战解析

1. 问题现场：一次看似普通却让人头疼的异步顺序错乱

先聊一个我实际踩过的坑。大概是去年下半年，我在给一个内部管理系统做前端页面，需求倒是不复杂：进入某个商品详情页时，需要先请求一遍“用户最近浏览记录”接口，拿到记录后把里面的最后一条商品ID取出来，再用这个ID去请求“商品详情”接口，最后把两份数据都渲染进页面里。

我当时很“自信”，直接在 mounted 里按顺序写了两个 $.ajax 调用，代码大概是这样的：

javascript复制let lastViewId = null;

$.ajax({
    url: '/api/recent-view',
    success: function (res) {
        lastViewId = res.data[res.data.length - 1].goodsId;
    }
});

$.ajax({
    url: '/api/goods/detail',
    data: { id: lastViewId },
    success: function (res) {
        renderPage(res.data);
    }
});

结果呢？第一次渲染出来的商品详情，永远是一个空壳，偶尔能跑出来一次，但也对不上最近浏览的那条记录。后来我在控制台打印日志才明白过来：第二个请求在发出的时候，lastViewId 还是 null，因为第一个请求根本还没回来。这就是最典型的“ajax 异步执行顺序错误”——你以为代码从上往下写，就一定会从上往下执行，实际上 ajax 请求发出去之后，响应什么时候回来并不由你控制。

这个问题看起来很简单，但它背后牵扯到 JavaScript 的事件循环机制、回调时机、以及我们日常写业务代码时最容易忽略的一个事实：ajax 请求不是函数调用，你没法保证“先请求的一定先返回”。

这篇文章我会结合自己实际排查和修复的经验，把这类“执行顺序错乱”的问题从原理到实战完整梳理一遍，包括为什么会出现、常见的几种表现形态、以及我在不同场景下分别采用的几种解法。如果你是刚接触前后端联调不久，或者虽然写了一阵子 ajax 但老是遇到“数据没拿到就往下走”的怪问题，这篇文章应该能帮你省下不少调试时间。

注意：下文所有接口地址和返回结构均为演示用，实际项目中请以你自己的后端契约为准。

2. 先搞懂为什么：ajax 到底是怎样“乱序”的

2.1 异步不等于“排队等待”

要理解执行顺序为什么会乱，得先回到 JavaScript 的执行模型。JavaScript 是单线程语言，同一时间只能干一件事。但浏览器环境给我们提供了 Web API（比如 XMLHttpRequest、fetch、定时器等），这些 API 的底层逻辑并不占用 JavaScript 主线程。

当一个 ajax 请求发出去后，浏览器会把它交给网络线程去处理，JavaScript 主线程不会停下来等响应，而是继续往下执行后面的代码。等网络线程收到了服务器的响应，它会把对应的回调函数塞进一个叫“任务队列”（Task Queue）的地方。主线程当前的任务都执行完了，才会从队列里把回调取出来执行。

这就是为什么你写了两个 ajax，第二个请求会在第一个响应回来之前就发出去的原因。它们俩都是“发完就撒手不管”，谁先回来谁先进入回调队列，而不是严格按照你写的代码顺序。

2.2 请求并发导致的竞态条件

再看一个我在实际项目里经常遇到的场景：页面上有一个“搜索”按钮，用户可能连续点击好几次，每次点击都会发送一个搜索请求。比如第一次点了“苹果”，第二次点了“香蕉”，由于网络波动或后端处理速度不同，很可能“香蕉”的响应先回来了，界面显示了“香蕉”的结果，几秒后“苹果”的响应也回来了，又把界面覆盖成了“苹果”的结果。

这时页面上显示的内容和用户最后的选择是不一致的。更麻烦的是，如果你在回调里做了“加载状态”控制，就会出现 loading 提前关闭、但后续又有数据覆盖的诡异现象。

这就是典型的竞态条件（Race Condition）。本质原因是 多个异步操作的完成顺序无法预测，而我们的业务逻辑却默认“最后一次操作的结果应该最后显示”。

2.3 回调嵌套带来的“代码顺序”错觉

另一类顺序错乱其实不发生在“多个独立请求”之间，而是发生在“有依赖关系的请求”之间——就像我在开头举的那个例子。代码里看起来是先写 A 请求、再写 B 请求，但因为 A 的响应还没回来，B 请求就已经带着 null 或 undefined 发出去了。

老手会想到用回调嵌套来解决：

javascript复制$.ajax({
    url: '/api/recent-view',
    success: function (res) {
        let lastViewId = res.data[res.data.length - 1].goodsId;
        $.ajax({
            url: '/api/goods/detail',
            data: { id: lastViewId },
            success: function (res) {
                renderPage(res.data);
            }
        });
    }
});

这样确实保证了顺序：第二个请求在第一个的成功回调里才发出去，响应数据也有了。但这样写的代价是代码嵌套层级变深，如果业务链路上有三四个请求，就会出现“回调地狱”，代码可读性直线下降。

所以“ajax 执行顺序错误”的表面问题是 响应时机不可控，但深层的工程问题其实是 我们缺少一套对异步流程进行编排的工具。

3. 核心解法一：从回调到 Promise，再到 async/await

3.1 用 Promise 封装一次 ajax 请求

在还没有 fetch 的年代，XMLHttpRequest 本身是不支持 Promise 的，jQuery 的 $.ajax 虽然返回了一个 jqXHR 对象，但它本质上还是回调风格。前端社区后来把这类异步操作封装成 Promise，才让“顺序编排”变得容易。

比如我们可以封装一个简单的 request 函数：

javascript复制function request(url, options = {}) {
    return new Promise((resolve, reject) => {
        $.ajax({
            url: url,
            method: options.method || 'GET',
            data: options.data || {},
            success: function (res) {
                resolve(res);
            },
            error: function (err) {
                reject(err);
            }
        });
    });
}

封装之后，之前的依赖场景就可以写成这样：

javascript复制request('/api/recent-view')
    .then(function (res) {
        let lastViewId = res.data[res.data.length - 1].goodsId;
        return request('/api/goods/detail', {
            data: { id: lastViewId }
        });
    })
    .then(function (res) {
        renderPage(res.data);
    })
    .catch(function (err) {
        console.error('请求出错：', err);
    });

这里的关键在于：then 回调里如果返回了一个新的 Promise，那么后续的 then 会等待这个 Promise 完成之后才执行。这样就保证了第二个请求一定是在拿到第一个请求的结果之后才发出去的。

3.2 async/await 让异步代码看起来像同步

Promise 相比回调嵌套已经好了很多，但如果你有多个串行步骤，.then 链写长了还是挺绕。ES2017 引入了 async/await 语法，它本质上是 Promise 的语法糖，但代码书写方式更接近我们习惯的“从上到下顺序执行”的思维方式。

还是刚才那个场景：

javascript复制async function loadGoodsDetail() {
    try {
        const recentRes = await request('/api/recent-view');
        const lastViewId = recentRes.data[recentRes.data.length - 1].goodsId;

        const detailRes = await request('/api/goods/detail', {
            data: { id: lastViewId }
        });

        renderPage(detailRes.data);
    } catch (err) {
        console.error('请求出错：', err);
    }
}

每遇到一个 await，当前函数就会“暂停”在那里，等待后面的 Promise 有了结果再继续往下执行。这样写出来的代码，在阅读的时候几乎不需要再做“大脑栈切换”，维护成本低了很多。

我在实际项目里，只要是有依赖关系的多个请求，一律优先使用 async/await。这已经成为我处理“ajax 顺序错误”的第一反应。

3.3 如果项目还在用 ES5，怎么办

我知道肯定有朋友会说：项目比较老，不能上 ES6+，或者团队规范不允许用 async/await。这种情况我还是建议至少用 Promise 加一个 polyfill，或者用 ES5 时代的“计数器”模式来管理多个请求的完成时机。

比如并行请求三个接口，全部回来之后再统一渲染：

javascript复制var total = 3;
var results = [];

function checkAllDone() {
    if (results.length >= total) {
        renderAll(results);
    }
}

$.ajax({
    url: '/api/a',
    success: function (res) {
        results[0] = res;
        checkAllDone();
    }
});

$.ajax({
    url: '/api/b',
    success: function (res) {
        results[1] = res;
        checkAllDone();
    }
});

$.ajax({
    url: '/api/c',
    success: function (res) {
        results[2] = res;
        checkAllDone();
    }
});

这种方式虽然朴素，但思路是对的：通过一个“完成计数”来聚合多个异步结果。后面你理解 Promise.all 时，会发现它做的事情本质上就是这件事，只是封装得更好、错误处理更完善。

3.4 真正的重点：串行与并行要分清

很多人写顺序代码出错，根源上是没有想清楚“哪些请求之间有依赖，哪些没有”。

我给自己定了一个简单的判断规则：

• 如果 B 请求需要用到 A 请求的返回数据，那 A 和 B 必须串行，B 只能在 A 完成之后发起。
• 如果 A 请求和 B 请求互不依赖，那它们应该并行发起，而不是先等 A 再发 B，否则白白浪费了用户等待时间。

对应到写法上，并行用 Promise.all：

javascript复制async function loadDashboard() {
    const [userRes, orderRes, messageRes] = await Promise.all([
        request('/api/user/info'),
        request('/api/order/list'),
        request('/api/message/unread')
    ]);

    renderUser(userRes.data);
    renderOrders(orderRes.data);
    renderMessages(messageRes.data);
}

串行用多个 await（或 Promise 链）：

javascript复制async function loadOrderDetail() {
    const orderRes = await request('/api/order/detail');
    const goodsRes = await request('/api/goods/detail', {
        data: { id: orderRes.data.goodsId }
    });
    renderDetail(orderRes.data, goodsRes.data);
}

这里有一个隐藏的性能点值得说一句：await 虽然方便，但它会把原本可以并行的请求强制变成串行。所以我在 Code Review 时，只要看到 await A(); await B(); 且 A、B 之间没有数据依赖，就会提醒对方改成 Promise.all。这是优化页面加载时间非常有效的一步。

4. 核心解法二：用防抖与请求序号解决“竞态覆盖”

4.1 一个真实的搜索联想 bug

前面说过，连续点击搜索或快速输入关键词时，多个请求的响应顺序可能和发出顺序不一致。这是第二种常见的“ajax 执行顺序错误”：不是参数没拿到，而是拿到了，却被晚到的旧响应覆盖了。

举个例子，我在做一个搜索联想组件时，用户每输入一个字就发一次请求。有次测试人员反馈：输入“abc”后，下拉框里出现了“a”的联想结果。我排查后发现，用户输入 a 时请求 A 发出，输入 ab 时请求 B 发出，输入 abc 时请求 C 发出。由于网络波动，A 的响应最晚才回来，渲染时直接把 C 的结果覆盖掉了。

这种问题用“保证有依赖”的思路是解决不了的，因为它们本来就互不依赖，你可以让它们并行，但结果不能互相破坏。

4.2 方案一：请求序号标记法

最简单的思路是：为每一次用户操作生成一个递增的序号，响应回来时带上这个序号，渲染前做一个判断——只响应最新一次请求。

javascript复制let requestSeq = 0;

function handleSearch(keyword) {
    const currentSeq = ++requestSeq;

    request('/api/search', {
        data: { keyword: keyword }
    }).then(function (res) {
        // 如果当前响应不是最新一次请求，直接丢弃
        if (currentSeq !== requestSeq) {
            return;
        }
        renderSuggestList(res.data);
    });
}

核心逻辑就一行判断：currentSeq !== requestSeq。请求发出去时记录当前序号，响应回来时如果序号已经不是最新了，说明有更新的请求已经发出，这个响应属于过期数据，直接无视。

这个方法的好处是：

• 实现简单，不需要额外引入库
• 兼容性极好，任何环境都能用
• 逻辑直观，代码审查一目了然

4.3 方案二：用 AbortController 真正取消旧请求

序号法的本质是“不处理旧响应”，但旧请求其实仍然在网络上传输，白白占用带宽。如果你想更彻底一点，可以在发出新请求时，把旧请求真正取消掉。浏览器为我们提供了 AbortController。

以 fetch 为例：

javascript复制let abortController = null;

function handleSearch(keyword) {
    // 取消上一次未完成的请求
    if (abortController) {
        abortController.abort();
    }

    abortController = new AbortController();

    fetch('/api/search?keyword=' + encodeURIComponent(keyword), {
        signal: abortController.signal
    })
        .then(function (response) {
            return response.json();
        })
        .then(function (data) {
            renderSuggestList(data);
        })
        .catch(function (err) {
            // 注意：主动 abort 会触发 error，这里要区分处理
            if (err.name === 'AbortError') {
                console.log('上一次请求已被取消');
                return;
            }
            console.error('搜索请求失败：', err);
        });
}

Ajax 老 API（XMLHttpRequest）也有对应的 xhr.abort() 方法，原理一样：新请求开始时，调用旧对象的 abort()，把它掐断。

用 AbortController 的好处是浏览器层面的任务真正消失了，不会再有“网络传输已完成但被忽略”的资源浪费。但它对老版本浏览器的支持度不如序号法，具体用哪一种，取决于你的用户群体。如果是内部管理系统，浏览器版本可控，我建议优先用 AbortController；如果是面向公网用户且要兼容老浏览器，就用序号法。

4.4 防抖不是“顺序控制”的替代品

在处理搜索联想、按钮点击这类高频场景时，很多教程会建议加“防抖”（debounce）：等用户停止输入 300 毫秒后再发请求。这确实能显著减少请求数量，但对于已经发出去的请求，防抖并不能阻止它们乱序返回。防抖和“响应丢弃/取消”是两个层面的事，建议一起用：

• 防抖负责“减少无意义的请求”
• 序号法或 AbortController 负责“保证乱序响应不会污染 UI”

两个都加，才能既省流量又不出 bug。我见过不少项目只做了防抖，以为“用户不会连续触发了，就不会乱序了”，结果在高频点击 + 弱网环境下依然复现数据覆盖问题。原因很简单：防抖只是让请求不那么密集，但不能保证不重叠，弱网下慢响应的概率依然很高。

5. 一个完整案例：从错误代码到生产级写法

5.1 需求描述

为了让上面的思路更好落地，我写一个能直接“抄作业”的完整示例。需求是一个“带搜索过滤的订单列表页”：

1. 页面加载时，先请求用户信息接口，拿到当前用户所属的“区域ID”。
2. 拿到区域ID后，再请求该区域下的订单列表。
3. 页面上有一个搜索框，输入关键字可以按订单号模糊搜索。
4. 搜索请求必须是最新一次输入为准，旧响应不能覆盖新结果。

5.2 错误写法演示

很多人会这样写：

javascript复制let regionId = null;
let orderList = [];

// 1. 获取区域
$.ajax({
    url: '/api/user/region',
    success: function (res) {
        regionId = res.data.regionId;
    }
});

// 2. 获取订单
$.ajax({
    url: '/api/order/list',
    data: { regionId: regionId },   // 这里 regionId 还是 null
    success: function (res) {
        orderList = res.data.list;
    }
});

// 3. 搜索
$('#searchInput').on('input', function () {
    const keyword = $(this).val();
    $.ajax({
        url: '/api/order/search',
        data: { keyword: keyword },
        success: function (res) {
            renderList(res.data.list);
        }
    });
});

三个问题：

1. 第二个请求发出时，regionId 还是 null。
2. 搜索接口的响应如果乱序，列表会被旧数据覆盖。
3. 如果搜索发生时订单列表还没加载完，两个请求会同时操作页面上的同一块 DOM，互相打架。

5.3 生产级写法

javascript复制// 封装统一的请求方法
function request(url, options = {}) {
    return new Promise(function (resolve, reject) {
        $.ajax({
            url: url,
            method: options.method || 'GET',
            data: options.data || {},
            success: function (res) {
                resolve(res);
            },
            error: function (xhr, status, err) {
                reject(err || new Error(status));
            }
        });
    });
}

// 用序号标记搜索请求
let searchSeq = 0;

// 初始化页面
async function initPage() {
    try {
        // 第一步：拿区域信息
        const userRes = await request('/api/user/region');
        const regionId = userRes.data.regionId;

        // 第二步：拿订单列表
        const orderRes = await request('/api/order/list', {
            data: { regionId: regionId }
        });

        renderList(orderRes.data.list);

        // 第三步：绑定搜索事件
        $('#searchInput').on('input', function () {
            const keyword = $(this).val().trim();
            handleSearch(keyword);
        });
    } catch (err) {
        console.error('页面初始化失败：', err);
    }
}

// 搜索处理：丢弃过期响应
function handleSearch(keyword) {
    const currentSeq = ++searchSeq;

    if (!keyword) {
        renderList([]);
        return;
    }

    request('/api/order/search', {
        data: { keyword: keyword }
    }).then(function (res) {
        if (currentSeq !== searchSeq) {
            return; // 过期响应，丢弃
        }
        renderList(res.data.list);
    }).catch(function (err) {
        console.error('搜索失败：', err);
    });
}

// 绑定额外事件：清空搜索时同步清空列表
$('#searchInput').on('keydown', function (e) {
    if (e.key === 'Escape') {
        $(this).val('');
        renderList([]);
    }
});

initPage();

如果项目可以放心使用 fetch 和 AbortController，搜索部分可以改成这样：

javascript复制let searchController = null;

function handleSearch(keyword) {
    if (searchController) {
        searchController.abort();
    }

    if (!keyword) {
        renderList([]);
        return;
    }

    searchController = new AbortController();

    fetch('/api/order/search?keyword=' + encodeURIComponent(keyword), {
        signal: searchController.signal
    })
        .then(function (response) {
            return response.json();
        })
        .then(function (data) {
            renderList(data.data.list);
        })
        .catch(function (err) {
            if (err.name === 'AbortError') return;
            console.error('搜索失败：', err);
        });
}

两种写法都行，我在实际项目中会根据团队技术栈选：老项目用 jQuery + Promise + 序号，新项目用 fetch + AbortController。

5.4 关键点在哪儿

表面上，上面的代码实现的是“先拿区域再拿订单，搜索以最新为准”。但你仔细想想，这些逻辑如果写成同步代码，几行就完事了。之所以要绕这么多弯子，就是因为 ajax 是异步的，而异步世界里“顺序”是需要显式维护的。

• 有依赖的请求：通过 async/await 或 Promise 链，把“下一步”牢牢绑定在“上一步完成之后”。
• 无依赖但有 UI 覆盖冲突的请求：通过序号或取消机制，把“不想要的响应”拦截在渲染之前。

这两条规则能覆盖 90% 以上的“ajax 执行顺序错误”。

6. 其他几个提升健壮性的建议

6.1 加载状态也应该“防过期”

有竞态问题的不只是渲染逻辑，加载状态也一样。比如你的页面有一个全局 loading 蒙层，请求 A 和请求 B 并行发出，A 先返回关闭了 loading，B 后返回才真正把数据渲染完整。用户可能在 A 返回后到 B 返回前这段时间里看到一片空白或残缺页面，甚至会误以为页面卡住了。

我的习惯是给 loading 控制加一个计数器或者标志位：

javascript复制let pendingCount = 0;

function showLoading() {
    pendingCount++;
    $('#loadingMask').show();
}

function hideLoading() {
    pendingCount = Math.max(0, pendingCount - 1);
    if (pendingCount === 0) {
        $('#loadingMask').hide();
    }
}

这样只有当所有请求都完成时，loading 才会关闭。比“哪个请求先回来谁就关 loading”要可靠得多。

6.2 正确处理“取消请求”时产生的错误

用 AbortController 或 xhr.abort() 时，有一个坑很容易踩：被取消的请求会触发 error 回调。很多人在 catch 里一律当成网络错误处理，于是页面上弹出一个“请求失败”的提示，用户体验很差——明明是用户自己发起了新操作，旧请求被主动取消，不应该算“失败”。

所以一定要在错误处理里判断错误类型：

javascript复制.catch(function (err) {
    if (err.name === 'AbortError') {
        // 主动取消，静默处理
        return;
    }
    // 真正的网络错误或服务端错误
    showErrorToast('网络异常，请稍后重试');
});

6.3 后端接口幂等性也是顺序问题的隐雷

有时候顺序错乱不是前端代码的问题，而是后端接口设计的问题。比如有一个“保存”接口，处理逻辑是先删除旧数据再插入新数据。如果用户连续保存两次，第一次请求还没处理完，第二次请求已经到了，后端对同一份数据做了并发修改，最终落库的结果可能既不是第一次的也不是第二次的，而是两者交错后的脏数据。

虽然这类问题主要靠后端解决，但前端也可以通过“请求互斥”来降低发生的概率——在保存请求未完成时，禁用保存按钮；或者使用全局的“请求锁”，同一时刻只允许一个写请求在途。这里我就不展开了，只是提醒大家：“ajax 执行顺序错误”有时并不完全是前端的锅。

6.4 用调试工具还原问题现场

排查顺序错乱类 bug 时，Chrome DevTools 的 Network 面板是最好用的工具。打开面板后，注意两个要点：

1. 看 Waterfall（时间轴）里的请求顺序和耗时，能直观看到哪个请求先发出、哪个先返回。
2. 在请求列表上右键，选择“Save all as HAR with content”，可以导出完整的请求记录，方便复现和分析。

控制台里加日志也很关键，但建议不要用 console.log 一把梭，可以简单地写一个带时间戳和标识的打印函数：

javascript复制function logWithTime(tag, value) {
    console.log(`[${new Date().toISOString()}] [${tag}]`, value);
}

这样当多个请求交错出现时，你能分清哪个日志属于哪个请求。

7. 常见问题速查与经验收尾

我把这几年遇到的“ajax 异步执行顺序错误”整理成一个速查表，供你在排查时快速定位：

7.1 我个人的一点经验

在处理这类问题的过程中，我最深的一个体会是：“认为写在前面的代码会先执行”是异步编程里最危险的直觉。

如果你总是用“同步思维”去写 ajax 代码，早晚会踩到顺序错乱的坑。从入行到现在，我自己踩过、也帮别人排过不下十次类似的问题，大部分情况都不是什么高深的技术难点，而是一开始没有想清楚要用的数据结构、没有规划好请求之间的依赖关系。

所以我给自己定了一个强制要求：凡是一个函数里出现两个以上 ajax 请求，写之前先画一遍它们之间的依赖关系图——有依赖就串行，无依赖就并行，有覆盖就做竞态控制。这个习惯帮我躲过了很多潜在 bug，也让我在 Code Review 时能更快发现别人代码里的异步隐患。

7.2 一个小技巧收尾

最后分享一个调试技巧。如果你怀疑某个数据是“旧请求晚到”造成的覆盖，但控制台日志乱得看不清，有一个笨但好用的办法：在渲染函数里临时打一个 debugger; 断点，让代码停在渲染前，然后查看调用栈和闭包变量，能帮你快速定位到是哪一次请求触发的渲染。

javascript复制function renderList(list) {
    // 临时断点，排查乱序问题时使用，排查完记得删除
    // debugger;
    // 实际渲染逻辑...
}

这个方法虽然土，但在复杂的竞态问题面前，往往比对着日志猜来猜去要高效得多。

希望这篇内容对你排查和解决 ajax 异步顺序问题有所帮助。如果你在项目里也遇到过类似的诡异现象，欢迎按文中的思路去试一试，尤其是“序号法”和“AbortController 取消旧请求”这两个方案，简单直接，能解决大部分实际痛点。