Promise.race 是实现超时控制最简洁有效的方式，通过让业务请求 Promise 与定时 reject 的 Promise 赛跑，首个 settled 的结果决定最终状态；需确保超时 Promise 使用 reject、每次新建 timer、配合 AbortController 真正中止请求。
Promise.race 是 JavaScript 中实现超时控制最简洁有效的方式之一，核心思路是让一个正常请求 Promise 与一个定时 reject 的 Promise 同时“赛跑”，谁先完成就采用谁的结果。
超时控制的基本结构
用 Promise.race 包裹两个 Promise：一个是业务请求（如 fetch），另一个是通过 setTimeout 封装的延迟 reject。一旦超时时间到，后者先触发 reject，整个 race 就立即失败，从而中断等待。
- 超时 Promise 必须是 reject 操作，否则无法中断成功响应
- 超时时间应略大于预期最长响应时间，避免误判（如网络抖动）
- race 返回的 Promise 状态由第一个 settled（fulfilled 或 rejected）的子 Promise 决定
封装可复用的 timeout 函数
把超时逻辑抽离成独立函数，提升可读性和复用性：
function timeout(promise, ms) {
const timer = new Promise((_, reject) => {
setTimeout(() => reject(new Error('Request timed out')), ms);
});
return Promise.race([promise, timer]);
}
使用时只需包装原始请求：
立即学习“Java免费学习笔记（深入）”；
timeout(fetch('/api/data'), 5000)
.then(res => res.json())
.catch(err => {
if (err.message === 'Request timed out') {
console.log('接口响应超时');
} else {
console.log('其他错误：', err);
}
});
注意 race 不会取消原始请求
Promise.race 只控制 Promise 状态，不会终止底层网络请求或异步操作本身。fetch 请求即使被 race reject，仍可能在后台继续执行并占用连接。
- 如需真正中止 fetch，应配合 AbortController 使用
- 对于定时器、自定义异步任务，需手动清理（如 clearTimeout）
- race + AbortController 可组合使用：超时触发 abort.signal，兼顾状态控制与资源释放
常见误用与规避
容易忽略的细节会影响超时逻辑的可靠性：
- 不要用 resolve 构造超时 Promise —— 这会让 race 成功返回 undefined，掩盖真实错误
- 避免在 timeout 函数里直接 throw —— Promise 构造器内 throw 会导致未捕获异常
- 多个并发请求共用同一 timeout 实例？不行 —— 每次调用都应新建 timer，否则超时逻辑会互相干扰
