Vue 组合式函数管理可取消请求的生命周期

我在一个搜索页里第一次遇到这个问题时，表面症状很像接口偶发变慢：用户连续输入关键词，旧请求却在新请求之后返回，结果列表又跳回旧内容。真正的处理重点不是给 fetch 加一个超时，而是让每次请求都拥有可取消的控制器，并把请求结果写回组件的条件收紧。

组合式函数应同时管理三件事：新请求开始时取消旧请求，响应落地前检查请求序号，组件卸载时取消仍在途的请求。主动取消单独归类，不要当成网络错误展示。

先把请求和组件生命周期绑在一起

Vue 官方建议组合式函数在组件卸载时清理自己创建的副作用；浏览器的 Fetch API 则通过 AbortController 的 signal 连接取消动作。下面这个骨架把两个边界放在同一个函数里：

import { ref, onUnmounted } from 'vue'

export function useCancelableRequest() {
  const data = ref(null)
  const error = ref(null)
  const loading = ref(false)
  let controller = null
  let requestId = 0

  async function run(url, options = {}) {
    // 新请求抢占旧请求，避免同一组件里并行回写。
    controller?.abort()
    controller = new AbortController()
    const currentId = ++requestId
    loading.value = true
    error.value = null

    try {
      // signal 让 fetch 能响应组件内的取消动作。
      const response = await fetch(url, {
        ...options,
        signal: controller.signal
      })
      if (!response.ok) throw new Error(`HTTP ${response.status}`)
      const result = await response.json()
      // 旧请求即使晚到，也不能覆盖最后一次请求的结果。
      if (currentId === requestId) data.value = result
      return result
    } catch (cause) {
      // 主动取消是预期分支，不应覆盖页面上的错误提示。
      if (cause?.name !== 'AbortError' && currentId === requestId) {
        error.value = cause
      }
      throw cause
    } finally {
      // 只有最后一次请求可以结束当前 loading 状态。
      if (currentId === requestId) loading.value = false
    }
  }

  onUnmounted(() => {
    // 组件离开页面时释放尚未完成的网络副作用。
    controller?.abort()
  })

  return { data, error, loading, run }
}

这里的 requestId 不是为了替代取消。取消只是通知底层请求尽快结束，序号守卫负责最后一道状态写入边界；两者叠加后，即使某个实现没有立刻停止底层工作，也不会让旧结果覆盖新结果。

用状态机确认哪些结果可以落地

在搜索框、筛选器和路由参数变化场景中，我会把结果分为五种状态：idle 表示尚未请求，loading 表示当前请求在途，success 表示最新请求成功，error 表示最新请求失败，canceled 则表示调用方主动停止。取消不一定要显示成错误，但日志里可以记录取消原因。

如果使用 watch 监听路由或输入值，组合式函数只保留一个对外的 run 入口即可：

import { ref, watch } from 'vue'
import { useCancelableRequest } from './useCancelableRequest'

const keyword = ref('vue')
const { data, error, loading, run } = useCancelableRequest()

watch(keyword, (value) => {
  // 业务层只负责拼接请求地址，取消和清理交给组合式函数。
  run(`/api/search?q=${encodeURIComponent(value)}`).catch((cause) => {
    // AbortError 是切换输入产生的正常分支，避免重复提示。
    if (cause?.name !== 'AbortError') console.error(cause)
  })
}, { immediate: true })

触发信号和快速排查顺序

看到旧数据回写时，先确认每次 run 是否递增序号，再确认响应落地前是否比较当前序号；只调用 abort() 而没有守卫，仍可能留下竞态。看到卸载后报错，检查 onUnmounted 是否在组合式函数同步执行时注册；Vue 生命周期钩子依赖当前组件实例，不能把注册动作延后到任意异步回调中。

SSR 场景不要在模块顶层直接访问 window 或立刻启动浏览器专属副作用。把需要 DOM 的逻辑放进 onMounted，请求本身则明确由客户端触发，或者把服务端预取与客户端刷新拆开。

回滚路径与边界清单

• 接口不支持取消时，保留请求序号守卫；它仍能阻止旧响应写入。
• 业务确实允许并行请求时，不要无条件取消上一请求，改用请求键分别维护控制器和序号。
• 组件被 KeepAlive 缓存时，卸载不等于离开激活状态；需要按业务决定在停用时暂停还是继续请求。
• 把 AbortError 从用户可见错误中分离，并为真正失败保留重试入口。

常见的两个误区

只在组件里写取消逻辑可以吗？可以，但多个页面重复实现后很容易漏掉旧响应守卫；组合式函数更适合统一生命周期。

finally 里直接把 loading 设为 false 可以吗？在允许重复请求时不安全。旧请求的 finally 可能先于新请求结束，必须用当前请求序号保护状态。