Promise.race是实现请求超时控制最简洁有效的方式之一,通过让请求Promise与超时Promise竞速,谁先settled就采用其结果,从而及时响应超时并做后续处理。

Promise.race 是实现请求超时控制最简洁有效的方式之一:它让多个 Promise 竞速,谁先 settled(fulfilled 或 rejected),就采用它的结果。只要把请求 Promise 和一个“超时 Promise”一起传入 race,就能自然实现超时中断逻辑。
核心思路:用 race 包裹请求和定时 reject
关键不是取消请求本身(原生 fetch/XHR 不支持直接取消,除非用 AbortController),而是让业务逻辑“不再等待超时的响应”。Promise.race 本身不终止网络请求,但它能让调用方及时拿到超时结果并做后续处理(比如提示用户、重试、跳转等)。
- 构造一个在指定毫秒后
reject('timeout')的 Promise - 把真实请求(如
fetch)和这个超时 Promise 一起传给Promise.race - 如果请求先完成,返回数据;如果超时先触发,整个 race 就 reject 超时错误
基础示例:fetch + timeout
以下是一个可直接运行的最小可行示例:
function timeoutFetch(url, timeout = 5000) {
const controller = new AbortController();
const timeoutId = setTimeout(() => controller.abort(), timeout);
return Promise.race([
fetch(url, { signal: controller.signal })
.then(res => {
clearTimeout(timeoutId);
return res;
}),
new Promise((_, reject) => {
setTimeout(() => reject(new Error('Request timed out')), timeout);
})
]);
}
// 使用
timeoutFetch('https://httpbin.org/delay/3')
.then(res => res.json())
.then(data => console.log(data))
.catch(err => console.error('Error:', err.message)); // 超时或网络错误都会走到这里
注意:上面用了 AbortController 配合 fetch 实现真正中断请求(现代浏览器支持),同时用 clearTimeout 避免内存泄漏。两个 Promise 竞速,谁先结束谁胜出。
封装成通用 timeout 工具函数
更灵活的做法是把超时逻辑抽离为高阶函数,适配任意 Promise:
function withTimeout(promise, ms) {
const controller = new AbortController();
const timeoutId = setTimeout(() => controller.abort(), ms);
return Promise.race([
promise,
new Promise((_, reject) => {
setTimeout(() => reject(new Error('Operation timed out')), ms);
})
]).finally(() => clearTimeout(timeoutId));
}
// 用法示例
withTimeout(fetch('/api/data'), 3000)
.then(res => res.json())
.catch(err => {
if (err.name === 'AbortError') {
console.log('Fetch was aborted');
} else if (err.message.includes('timed out')) {
console.log('Timeout occurred');
}
});
这样写复用性更强,也更容易统一错误处理策略。
注意事项与常见陷阱
实际使用中容易忽略几个细节:
- 超时 Promise 必须 reject,不能 resolve:否则 race 可能返回一个“假成功”的值,掩盖真实失败
-
fetch 的 signal abort 和 timeout reject 是两回事:abort 触发的是
AbortError,而超时 reject 是自定义错误,需分开判断 - 不要忽略 clearTimeout:避免超时回调在 Promise 已完成之后还执行,造成潜在副作用
- race 不等于 cancel:即使 race 返回了超时错误,原请求可能仍在后台进行(尤其没配 AbortController 时),注意服务端资源消耗
不复杂但容易忽略细节,掌握竞速逻辑和清理时机,就能稳稳控住超时体验。
Java免费学习笔记:立即使用
解锁 Java 大师之旅:从入门到精通的终极指南











