如何识别Promise.race超时逻辑

本文深入解析了 Promise.race 超时防御的四大关键实践：必须用 reject 触发超时 Promise 以确保可捕获、每次请求独立创建 timeout 实例避免状态污染、通过自定义 TimeoutError 类并配合 instanceof 精准识别超时错误（而非脆弱的字符串匹配）、以及结合 AbortController 主动中断 fetch 请求并统一转换 abort 异常为 TimeoutError，从而真正实现健壮、可维护、语义清晰的前端超时控制机制。

超时 Promise 必须用 reject 触发

如果定时器 Promise 用 resolve，race 会提前返回 undefined 或空值，掩盖真实错误，导致业务逻辑误判。正确做法是只在定时器中调用 reject，确保 race 状态为 rejected，让 catch 能明确捕获超时分支。

每次请求都新建 timeout Promise

复用同一个定时器 Promise 会导致状态残留或多次触发异常。应确保每个请求都生成独立的 timeout 实例：

• 避免在函数外定义并重复传入 timeout Promise
• 封装函数内部创建 new Promise + setTimeout，不缓存 timer 变量
• 防止因前序请求未完成而干扰当前 race 判定

区分超时错误与其他错误类型

仅靠 err.message === 'Request timed out' 容易被服务端返回的同名错误干扰。更稳妥的方式是：

• 自定义 TimeoutError 类，继承 Error 并设置唯一 name（如 'TimeoutError'）
• 在 catch 中用 err instanceof TimeoutError 判断，而非字符串匹配
• 超时错误信息里带上毫秒数（如 'Timeout: 5000ms'），便于定位配置问题

配合 AbortController 真正中断网络请求

Promise.race 只控制 Promise 状态，不终止底层 fetch 请求。若不干预，超时后请求仍在后台运行，浪费连接与带宽：

• 创建 AbortController 实例，将 signal 传入 fetch 配置
• 在超时 Promise 的 setTimeout 回调中调用 controller.abort()
• 注意：abort 后 fetch 会抛出 AbortError，需在 catch 中统一转为 TimeoutError，保持错误语义一致

理论要掌握，实操不能落！以上关于《如何识别Promise.race超时逻辑》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！