前端搜索建议怎么避免旧结果覆盖新输入：请求序号、AbortController 与并发预算

搜索框里连续输入“go”“golang”“golang 泛型”时，最危险的不是接口慢，而是旧请求可能比新请求更晚返回，结果列表因此跳回旧关键词。可靠的做法是把“当前请求是谁”当成组件状态：新输入先让上一请求失效，再用请求序号拒绝过期响应，同时把并发数控制在明确预算内。

先看现场：为什么慢接口会把新结果改回旧结果

假设用户先输入 go，随后马上输入 golang。浏览器会发出两个请求，服务端处理时间却不一定按发送顺序完成。

async function search(keyword) {
  const response = await fetch(`/api/suggest?q=${encodeURIComponent(keyword)}`)
  return response.json()
}

input.addEventListener('input', async (event) => {
  const rows = await search(event.target.value)
  renderSuggestions(rows)
})

如果 golang 的响应先到，列表先显示正确结果；随后较慢的 go 响应仍会调用 renderSuggestions，界面就出现“输入框是新词，建议却是旧词”的错位。这个问题不是 DOM 渲染慢，而是响应没有携带可验证的身份。

把请求身份放进状态：序号比时间判断更可靠

组件每次准备发起搜索时递增一个序号，响应回来后只接受仍等于当前序号的结果。序号不依赖网络时间，也不需要猜测哪一个请求更快。

let requestVersion = 0

async function loadSuggestions(keyword) {
  const version = ++requestVersion
  const response = await fetch(`/api/suggest?q=${encodeURIComponent(keyword)}`)
  const rows = await response.json()

  if (version !== requestVersion) {
    return
  }
  renderSuggestions(rows)
}

这里的判断是正确性门槛：只要用户再次输入，旧版本就算成功返回，也只能被丢弃。它仍然允许旧请求继续占用连接，所以还需要取消机制处理资源回收。

取消上一请求：AbortController 解决浪费，不替代序号

每一轮搜索保存自己的 AbortController。新关键词到来时先取消上一轮，再创建新的控制器。取消可能发生在请求刚发出、响应头已到或响应体读取中，因此错误处理应识别 AbortError，不要把用户主动取消显示成网络故障。

let requestVersion = 0
let activeController = null

async function loadSuggestions(keyword) {
  const version = ++requestVersion
  activeController?.abort()

  if (!keyword.trim()) {
    activeController = null
    renderSuggestions([])
    return
  }

  const controller = new AbortController()
  activeController = controller

  try {
    const response = await fetch(
      `/api/suggest?q=${encodeURIComponent(keyword)}`,
      { signal: controller.signal }
    )
    const rows = await response.json()

    if (version === requestVersion) {
      renderSuggestions(rows)
    }
  } catch (error) {
    if (error.name !== 'AbortError' && version === requestVersion) {
      renderError('暂时无法获取建议')
    }
  } finally {
    if (version === requestVersion) {
      activeController = null
    }
  }
}

即使调用了 abort()，也不能删掉版本判断：取消与响应到达之间存在竞态，某些响应可能已经进入解析阶段。控制器负责尽快停止工作，版本负责决定结果能否改变界面。

这个模式适合什么压力：输入频率和请求预算要一起看

单个搜索框通常只保留一个活动请求就够了；如果页面同时支持多个字段、预取热门词或分页加载，就不能简单地让每次输入都无限发起请求。把并发预算写成显式规则，才能知道什么时候排队、什么时候丢弃。

预算不是越大越快。搜索接口如果每次都返回几百 KB，八个并发请求会把解析和渲染压力转移到主线程，用户看到的反而是输入延迟。先测平均响应体、服务端限流和渲染耗时，再定上限。

反例：只 debounce、只 abort 或只比较关键词都不够

防抖只能减少请求数量，不能保证已经发出的请求按顺序返回；网络抖动仍会让旧响应晚到。只调用 abort() 能降低浪费，却没有替代响应身份校验的责任。直接比较响应里的关键词也不稳，因为服务端可能规范化大小写、去掉空格，或者响应没有回显查询词。

更隐蔽的反例是把 activeController 在所有 finally 中无条件置空。旧请求的清理晚于新请求时，会把新控制器的引用误删，下一次输入就无法取消真正的活动请求。清理动作必须再次确认版本归属。

把用户任务补完整：空状态、错误和键盘选择

搜索建议不是只有“有数据”一种状态。空输入应清空列表并关闭候选区；正在请求时可以保留上一次结果但要显示忙碌状态；当前请求失败时给出重试入口；用户按方向键选中后，回车应提交输入框中的候选值，而不是重新读取已经过期的数组索引。

function acceptSuggestion(item) {
  input.value = item.label
  closeSuggestions()
  input.dispatchEvent(new Event('change', { bubbles: true }))
}

如果候选项来自不同关键词，键盘索引也要和当前版本绑定。渲染新列表时重置高亮项，列表关闭或请求失败时清除旧的选中状态，避免按回车提交用户看不见的旧候选。

验证边界：用可控延迟复现三类结果

测试时不要只点几下输入框。为测试接口注入延迟，让短词故意晚于长词返回，并检查最终列表、取消次数和错误提示。

it('keeps the newest keyword result', async () => {
  type('go')
  type('golang')
  resolveRequest('golang', [{ label: 'golang 泛型' }])
  resolveRequest('go', [{ label: 'Go 教程' }])

  await flushPromises()
  expect(list.textContent).toContain('golang 泛型')
  expect(list.textContent).not.toContain('Go 教程')
})

再补三组检查：空输入不会发请求；新输入会取消上一控制器；当前请求返回错误时才显示错误提示。若这些断言稳定通过，组件的正确性、资源回收和用户反馈才算同时闭合。

相关问题

搜索框一定要使用防抖吗？

不一定，但高频输入通常需要防抖或最小长度门槛来降低请求量。防抖只负责触发节奏，仍要保留版本校验。

AbortController 取消后还要判断版本吗？

要。取消是资源回收动作，版本判断是界面正确性动作，两者解决的是不同问题。

为什么不能在每次输入时直接清空候选列表？

可以清空，但更好的体验是区分等待、空结果和失败。若保留旧列表，必须明确它不再接受键盘提交，避免显示内容和当前关键词混淆。

小结

前端搜索建议的核心不是把接口调用包进一个 async 函数，而是建立清楚的请求生命周期：新输入产生新版本，旧请求尽快取消，响应只有在版本仍有效时才能更新界面，并发数量还要有可解释的预算。把这些规则和键盘、空输入、失败重试一起测试，搜索框才不会在慢网络下失去可信度。