Promise.race能控制fetch超时，因其返回首个settled的Promise；通过并行封装fetch和setTimeout为Promise，超时即reject并abort请求，确保及时中断。
Promise.race 为什么能用来控制 fetch 超时
因为 Promise.race 返回第一个 settled（fulfilled 或 rejected）的 Promise，而 fetch 和 setTimeout 可以包装成两个并行 Promise：一个负责网络请求，一个负责计时中断。只要任一完成，race 就立刻返回结果——这正是超时控制的核心逻辑。
注意：不能只靠 fetch().then(...).catch(...) 捕获超时，因为 fetch 在网络卡死时不会 reject，它会一直 pending，直到浏览器强制终止（可能长达几分钟）。
怎么把 setTimeout 包装成可 race 的 Promise
直接调用 setTimeout 不返回 Promise，必须手动封装。关键点是：超时触发时要主动 reject，且错误对象最好带标识，方便后续区分是超时还是网络错误。
- 不要写
new Promise(resolve => setTimeout(resolve, ms))—— 这样 resolve 后 race 返回的是 undefined，无法判断原因 - 正确做法是
new Promise((_, reject) => setTimeout(() => reject(new Error('timeout')), ms)) - 错误信息字符串建议固定为
'timeout'或检查err.name === 'AbortError'以外的标识，避免和 AbortController 冲突
fetch + timeout race 的最小可靠写法
以下代码在现代浏览器中可直接运行，无依赖，兼容性好（Chrome 46+、Firefox 40+、Safari 10.1+）：
立即学习“前端免费学习笔记（深入）”；
function fetchWithTimeout(url, options = {}, timeout = 5000) {
const controller = new AbortController();
const { signal } = controller;
const fetchPromise = fetch(url, { ...options, signal });
const timeoutPromise = new Promise((_, reject) =>
setTimeout(() => {
controller.abort(); // 防止 fetch 继续占用连接
reject(new Error('timeout'));
}, timeout)
);
return Promise.race([fetchPromise, timeoutPromise]);
}
// 使用示例
fetchWithTimeout('/api/data', { method: 'POST' }, 3000)
.then(res => res.json())
.catch(err => {
if (err.message === 'timeout') {
console.error('请求超时');
} else if (err.name === 'AbortError') {
// controller.abort() 触发的，已由 timeoutPromise 处理，此处通常不会进
} else {
console.error('网络或解析错误', err);
}
});
重点：controller.abort() 必须在 timeout 时调用，否则 fetch 可能继续挂起，浪费连接池资源；signal 传给 fetch 是为了确保 abort 能真正中断底层请求（尤其对大文件上传/长轮询重要）。
容易被忽略的边界问题
实际项目中这几个点常导致“超时没生效”或“报错难定位”：
-
Promise.race对于已 resolve 的 Promise 不再响应后续 reject —— 所以 timeoutPromise 的reject即使晚于 fetch 完成，也不会影响结果，这是预期行为 - 如果后端响应头含
Connection: keep-alive，但客户端超时 abort 后，该 TCP 连接仍可能被复用；这不是 bug，是 HTTP/1.1 正常表现 - Safari 对
AbortController的abort()在某些旧版本中不触发 fetch reject，需降级 fallback（比如只靠 race + timeoutPromise reject，不依赖 signal） - 不要在 race 外层再套一层
try/catch试图捕获同步错误——fetch本身是异步的，语法错误或 URL 无效等会在 Promise 中 reject，直接走.catch即可
超时控制真正的复杂点不在 race 写法，而在 abort 是否真正生效、是否干扰重试逻辑、以及服务端是否感知到中断。这些得结合具体 API 行为来验证，不能只看前端 Promise 状态。
