先看看你的超时处理有没有这些坑

很多 Node.js 项目还在用 Promise.race 或手动 setTimeout 包装来做请求超时，但这类做法往往埋着几个常见坑：定时器忘了清除、请求中断后 Promise 仍在后台运行、无法区分超时和主动取消。一个常见坑是忘记在请求完成后清除 setTimeout，导致定时器仍然执行 abort() 并抛出未处理的拒绝。应在 then/catch 或 finally 中 clearTimeout。另外，不要在中止后继续使用同一个 controller 实例，需要新建。还有，部分库（如 request 的旧版本）不支持 signal，需确认依赖的兼容性。这些问题在流量上来后很容易暴露，先检查一遍现有代码里有没有类似模式。

改用 AbortController 的基本路径

使用 AbortController 优化超时处理的第一步是创建一个 AbortController 实例，并将其 signal 传递给 fetch 或类似请求函数。然后通过 setTimeout 在指定时间后调用 controller.abort() 来中断请求。这种方式比传统的超时封装更可靠，因为它直接与 Fetch API 的终止机制集成，避免因 Promise 未决而导致的资源泄漏。具体操作时，先确认你的请求库是否支持 signal 参数。Node.js 内置的 fetch（v18+）、undici、node-fetch v3 以及 axios v0.22+ 都支持。如果不支持，可能需要升级库或改用 polyfill。

const controller = new AbortController();
const timeoutId = setTimeout(() => controller.abort(), 5000);

fetch(url, { signal: controller.signal })
  .then(response => response.json())
  .then(data => { /* 处理数据 */ })
  .catch(err => { /* 处理错误 */ })
  .finally(() => clearTimeout(timeoutId));

注意 finally 里清掉定时器，避免请求提前完成后定时器仍然触发 abort()，导致未捕获的错误。

错误区分：是超时还是用户取消

捕获到 abort 错误后，应区分是超时还是用户主动取消。通过检查 error.name 是否为 'AbortError' 来判断。如果是超时，可考虑重试或降级；若是用户取消则忽略。注意在重试逻辑中重置 AbortController，避免使用已中止的 signal 再次发起请求。同时记录超时日志，便于监控网络稳定性。一个常见的错误处理模式如下：

.catch(err => {
  if (err.name === 'AbortError') {
    // 超时或已取消，根据场景判断
    if (timeoutFlag) {
      // 重试或降级
    }
  } else {
    // 其他错误
  }
})

这里 timeoutFlag 可以在 abort() 前设置，用于区分是定时器触发的还是用户主动调用。如果不做区分，超时和取消会混在一起，影响后续重试策略的准确性。

超时时间怎么选，参考什么指标

设置超时时间需权衡用户期望与服务能力。例如，对内部微服务可设 2–5 秒，对外部 API 适当放宽至 10–30 秒。若超时过短，正常慢请求会频繁失败；超时过长则拖累整体响应时间。观察生产环境 p95/p99 延迟，并结合业务容忍度动态调整，但不要依赖单一固定值。可以先从历史日志中提取延迟分布，取 p99 延迟乘以 1.5–2 作为初始超时值，再逐步收窄。如果统一超时导致某些接口频繁超时，考虑按接口维度独立配置。

并发请求与独立 controller

当同时发起多个请求并需要独立超时时，应为每个请求创建独立的 AbortController，避免共享 signal 导致一个超时影响其他请求。如果所有请求共享同一超时需求，可复用同一个 controller，但需确保在第一个请求完成后及时清理定时器，防止意外中止后续请求。推荐每个请求一个 controller，清晰且安全。实现时可以用一个工厂函数来创建请求并绑定独立的超时逻辑，减少重复代码。

function fetchWithTimeout(url, timeoutMs) {
  const controller = new AbortController();
  const timer = setTimeout(() => controller.abort(), timeoutMs);
  return fetch(url, { signal: controller.signal })
    .finally(() => clearTimeout(timer));
}

改完后检查这几个信号

迁移到 AbortController 后，需要观察几个关键信号：一是日志中是否出现 AbortError 的未捕获异常——通常是因为 finally 中没清定时器，或者 catch 分支没处理 AbortError；二是超时后的重试次数是否合理，避免重试风暴；三是使用 process.on('unhandledRejection') 监听是否有未被处理的 reject。另外，可以临时在开发环境用 --abort-on-uncaught-exception 跑测试，看是否有潜在的中止路径遗漏。如果迁移后出现请求数下降但错误率上升，先检查是否所有分支都处理了 signal.aborted 状态。最后，回滚预案很简单：切回原来的 Promise.race 或 request-promise 的逻辑，但建议只作为过渡，长期还是应该保持 AbortController 的统一实现。