Fetch 怎样用 AbortSignal.timeout 设置请求超时

把 AbortSignal.timeout(毫秒数) 返回的 signal 传给 Fetch 的选项即可设置超时，例如 fetch(url, { signal: AbortSignal.timeout(6000) })。超时会中止该信号，原因是名为 TimeoutError 的 DOMException。若还要读取 JSON，应把响应体读取也放进同一个异步处理范围。

官方地址：https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal/timeout_static

把等待预算绑定到每次请求

一个明确的设计约定是：每次请求拥有自己的等待预算与取消信号，调用者负责决定失败后如何提示。这比把六秒写成整个应用共享的状态更容易表达“这一次读取已经等得太久”。六秒只是本文示例，不是接口性能标准。

仅让 Promise.race 返回一个超时错误，并不等于底层 Fetch 已收到中止要求。这里选择把 signal 交给 Fetch，使异步操作与中止语义连接起来；但它不是服务端任务撤销协议，也不会保证服务端业务回滚。

结构上，等待预算 决定 AbortSignal.timeout 的输入，它返回 signal，供 fetch 使用；Response 与 响应体读取 则属于这次读取的响应对象。不要把 signal 只看成一个用来改变界面文字的计时器。

最小封装同时等待响应体

下面的原创浏览器示例只演示同源 GET JSON 读取。示例接口并非已确认存在的线上服务；代码没有实际执行，也没有运行截图。

async function readJsonWithin(url, budgetMs = 6000) {
  // 拒绝不支持的环境，避免悄悄发送没有超时约束的请求。
  if (typeof AbortSignal === "undefined" ||
      typeof AbortSignal.timeout !== "function") {
    throw new Error("当前环境不支持 AbortSignal.timeout");
  }
  // 这里要求正整数预算，属于此封装的业务约束。
  if (!Number.isSafeInteger(budgetMs) || budgetMs  {
    console.log("读取成功", data);
  })
  .catch((error) => {
    if (error?.name === "TimeoutError") {
      console.warn("请求等待超时，请稍后再试");
    } else {
      console.error("请求未完成", error);
    }
  });

这段封装刻意不接受外部 signal，也没有重试或用户取消入口，以免把多个中止来源混进本文的超时判断。请求路径和预算由调用方给出；输入不符合本例约定时，在创建请求前直接报错。

return await response.json() 并不是为了多写一个 await，而是让响应体失败能进入当前 catch。若直接返回读取 Promise，封装里的 catch 就不会接住它后续的拒绝。Response 已返回，也不表示 JSON 已读取完成。

超时原因与其他异常分别处理

Fetch 等待阶段超时与响应体读取中止的表面错误名称可能不同，所以示例同时保留原始 error 和信号的 signal.reason。只有遇到中止相关错误、且该信号已因 TimeoutError 中止，才返回超时原因。

这里的错误模型包含 原始 error、signal.aborted、signal.reason、TimeoutError 与 其他失败。不把所有 TypeError 都解释成浏览器不支持，因为请求本身也可能因其他原因失败。

截止时间不是绝对墙钟保证

timeout 使用活动时间，而非简单的现实经过时间；文档进入往返缓存或 worker 被挂起时，计时可能暂停。因此，6000 并不是任何环境都必须在现实六秒整结束的承诺。

它也不能抢占已经执行的同步 JavaScript 处理。下载完成后的数据计算、页面渲染和业务状态变化应有各自的设计约束，不能把一个 Fetch signal 宣称为整个函数的强制截止时间。

成功读取并不提供取消这个 timeout 的接口。本文没有添加自己的 abort 监听器；如果扩展封装时加了监听器，应在不再需要时移除。不要靠长期保留请求信号来管理页面级状态。

按支持范围决定是否采用

目标环境可能包含旧浏览器，应先检测 timeout 方法。本例选择明确报“不支持”，不悄悄退化成无限等待的 Fetch。若产品要求兼容更旧环境，可另设计 AbortController 与定时器方案，并处理定时器清理；那不是原生活动时间语义的无差别替代。

适合采用的场景是：调用方只需为一次异步读取规定等待预算，能够分别处理超时与其他失败，并知道这不是远端业务撤销。若需要手动取消、多个来源合并或完整重试策略，应先定义取消原因与业务边界，再扩展接口。

能把同一个 timeout signal 留给下一次请求吗？

不应把已中止的 signal 重新当作新请求的预算。本文每次调用都新建 signal，避免让后续调用继承之前的状态。

只收到响应头，就算读取成功了吗？

不算本例的成功。函数以 JSON 读取完成为返回条件；响应体阶段的中止或解析失败仍应向调用者传播。

超时后应立即自动重试吗？

本文不自动重试。是否重试应结合请求幂等性和产品交互决定，不能仅因出现 TimeoutError 就重复有副作用的操作。

参考：https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal/timeout_static；https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal；https://developer.mozilla.org/en-US/docs/Web/API/Window/fetch；https://developer.mozilla.org/en-US/docs/Web/API/Response/json。