前端搜索结果倒退怎么办：AbortController 取消旧请求和序号兜底

前端搜索框最容易被忽略的问题，不是接口慢，而是接口返回顺序不可控。用户快速输入“g、go、golang”，浏览器可能同时发出多次请求；新请求先返回，页面已经展示了正确结果，随后旧请求慢慢回来，又把列表覆盖成旧关键词的数据。

这类问题看起来像后端返回错了，实际经常是前端状态更新没有做保护。我们按一次排查过程来走：先复现结果倒退，再确认响应顺序，最后用 AbortController 和请求序号把旧响应挡住。

摘要

搜索结果倒退的根因通常是请求乱序：旧请求晚返回，却仍然更新了页面。修复思路有两层：第一层是在新输入出现时取消旧请求；第二层是给每次请求分配递增序号，只有最新序号的响应才允许写入状态。两层一起用，能同时处理取消失败、缓存返回和异常网络场景。

适合人群

• 正在做搜索框、筛选列表、远程下拉框的前端开发者。
• 遇到过接口返回顺序乱、旧数据覆盖新数据的问题。
• 想把前端请求状态从“能用”提升到“稳定可控”的同学。

问题现场：搜索框快速输入后结果倒退

先看一个典型现象：用户输入 g 时发起请求 A，输入 go 时发起请求 B，输入 golang 时发起请求 C。请求 C 先返回，列表显示了 golang 的结果；过了一会儿，请求 A 又返回，把页面覆盖成 g 的结果。

这一步说明，页面看到的最终结果，不一定来自最后一次输入。只要旧响应还能更新状态，就存在结果倒退的风险。

先复现：没有保护时旧响应会覆盖结果

下面是一段简化代码。每次输入变化都发请求，拿到结果后直接更新列表。

let keyword = '';
let results = [];

async function search(nextKeyword) {
  keyword = nextKeyword;

  const res = await fetch('/api/search?q=' + encodeURIComponent(nextKeyword));
  const data = await res.json();

  results = data.items || [];
  render(results);
}

这段代码的问题是：它默认“先发出的请求一定先回来”。但真实网络里，这个假设不成立。后发请求可能先回来，先发请求也可能最后才回来。

继续验证：问题不在后端，而在返回顺序

接着我们给每次请求加一点日志，把请求关键词和返回时间打出来。

async function search(nextKeyword) {
  const startedAt = Date.now();
  console.log('start', nextKeyword, startedAt);

  const res = await fetch('/api/search?q=' + encodeURIComponent(nextKeyword));
  const data = await res.json();

  console.log('done', nextKeyword, Date.now() - startedAt);
  render(data.items || []);
}

如果日志里出现下面这种顺序，就能定位到问题：

start g
start go
start golang
done golang
done go
done g

这说明后端并没有返回错，只是不同请求的耗时不同。前端如果不判断“当前响应是否还有效”，旧响应就会覆盖新界面。

修复方案一：用 AbortController 取消旧请求

第一层修复是取消旧请求。新关键词进来时，把上一次还没完成的请求取消掉。

let lastController = null;

async function search(nextKeyword) {
  if (lastController) {
    lastController.abort();
  }

  const controller = new AbortController();
  lastController = controller;

  try {
    const res = await fetch('/api/search?q=' + encodeURIComponent(nextKeyword), {
      signal: controller.signal,
    });
    const data = await res.json();
    render(data.items || []);
  } catch (err) {
    if (err.name === 'AbortError') {
      return;
    }
    showError('搜索失败，请稍后重试');
  }
}

这样做可以减少无意义请求，也能避免很多旧响应继续更新页面。但只靠取消还不够稳，因为某些响应可能已经进入完成阶段，或者业务代码里还有缓存、重试、并发入口。

修复方案二：用请求序号只认最新结果

第二层修复是请求序号。每次搜索都递增一个数字，响应回来后检查它是不是当前最新序号。

let currentSeq = 0;

async function search(nextKeyword) {
  const seq = ++currentSeq;

  const res = await fetch('/api/search?q=' + encodeURIComponent(nextKeyword));
  const data = await res.json();

  if (seq !== currentSeq) {
    return;
  }

  render(data.items || []);
}

这个判断很关键：旧响应即使回来了，也只能被丢弃，不能写入 UI。

完整代码：取消和序号一起用

实际项目里建议两层一起用：取消旧请求减少浪费，请求序号保证状态安全。

let currentSeq = 0;
let lastController = null;

async function search(nextKeyword) {
  if (!nextKeyword.trim()) {
    render([]);
    return;
  }

  if (lastController) {
    lastController.abort();
  }

  const seq = ++currentSeq;
  const controller = new AbortController();
  lastController = controller;
  setLoading(true);

  try {
    const res = await fetch('/api/search?q=' + encodeURIComponent(nextKeyword), {
      signal: controller.signal,
    });
    const data = await res.json();

    if (seq !== currentSeq) {
      return;
    }

    render(data.items || []);
  } catch (err) {
    if (err.name === 'AbortError') {
      return;
    }
    if (seq === currentSeq) {
      showError('搜索失败，请稍后重试');
    }
  } finally {
    if (seq === currentSeq) {
      setLoading(false);
    }
  }
}

这段代码里，列表、错误提示和 loading 都要检查序号。否则可能列表保护住了，loading 却被旧请求提前关闭。

常见误区

误区一：只做防抖就够了

防抖可以减少请求数量，但不能保证响应顺序。用户慢一点输入、网络波动或后端耗时不稳定时，仍然可能出现旧响应覆盖。

误区二：只取消请求，不检查序号

取消请求是好习惯，但序号判断是最后一道状态保护。只要响应有机会进入后续逻辑，就应该判断它是否仍然是最新请求。

误区三：只保护列表，不保护 loading 和错误状态

搜索体验不只列表一项。旧请求也可能把 loading 关掉，或者弹出已经过期的错误提示。相关状态都要按最新序号更新。

总结

前端搜索结果倒退，本质是请求乱序和状态更新缺少保护。我们先通过日志确认返回顺序，再用 AbortController 取消旧请求，最后用请求序号只允许最新响应更新 UI。

落地时可以记住一句话：新输入出现时取消旧请求，响应回来时检查序号。这样无论网络怎么波动，页面最终都只显示用户最后一次输入对应的结果。