Promise.race能控制超时是因为它返回第一个settled的Promise，将请求与包装好的超时Promise一起传入即可实现超时中断，兼容性好但需手动包装setTimeout、主动清理未完成请求并配合AbortController提升健壮性。
Promise.race 为什么能控制超时
因为 Promise.race 返回第一个 settled（fulfilled 或 rejected）的 Promise，所以可以把真实请求和一个延迟 reject 的 setTimeout 封装成的 Promise 一起传入——谁先完成，就用谁的结果。超时逻辑不依赖请求本身是否支持 abort，兼容性好，适合老接口或简单场景。
常见错误是把 fetch 和 setTimeout 直接丢进 race，但 setTimeout 不返回 Promise，必须手动包装；还有人忘了处理被 race 掉的请求，导致内存泄漏或重复响应。
- 必须用
new Promise((_, reject) => setTimeout(() => reject(new Error('timeout')), ms))包装超时逻辑 -
fetch成功后不会自动取消，建议配合AbortController主动中断（虽非必须，但更健壮） - 超时错误类型最好是
Error实例，方便后续用err.name === 'AbortError'或自定义字段区分
基础写法：fetch + 超时 Promise 封装
下面是最小可用示例，5 秒超时：
HTTP ${res.status}
注意：controller.signal 是可选但推荐的——它让 fetch 真正中断连接，避免后台还在传输数据；而仅靠 race 只是忽略结果，不终止网络行为。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
常见坑：race 后 fetch 仍在运行，且可能触发 then/catch
即使 Promise.race 返回了超时错误，原始 fetch 仍可能在之后 resolve 或 reject，如果没做清理，会意外执行后续逻辑（比如弹窗、更新状态），造成竞态 bug。
- 不要在
race外层直接写.then(...).catch(...)，所有处理必须收束在race返回的 Promise 链内 - 若需复用
fetch实例，务必调用controller.abort()在超时后主动清理（上面示例中signal已自动处理） - Node.js 环境无
AbortController时，只能靠 race 忽略结果，此时要确保业务逻辑不依赖“fetch 一定结束”
需要 retry 时，如何与 race 组合
不能把整个 retry 循环包进一个 race，否则一次超时就终止全部重试。正确做法是每次重试都生成独立的超时 Promise：
HTTP ${res.status}
这里每次循环都新建 AbortController 和超时 Promise，保证每次重试都有独立的超时边界。容易忽略的是：超时错误不应重试，否则可能无限卡在 timeout 上。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
