async/await 本身不提供超时能力，需借助 Promise.race 或 AbortController 实现；fetch 优先用 AbortController 真正中止请求，其他场景可用 withTimeout 封装 race，错误需明确识别并分层处理。

async/await 本身不提供超时能力，必须借助 Promise.race 或 AbortController 等机制来实现。关键不是“要不要用”，而是“在哪用、怎么用才稳妥”——尤其要避免超时后资源未释放、错误被吞、或逻辑错乱。

用 Promise.race 包装异步操作，是最直接的超时入口

把 await 的目标换成 Promise.race([原 Promise, 超时 Promise])，就能让 async 函数在超时后立即抛出错误。这种方式轻量、兼容性好，适合大多数 fetch、API 调用或简单定时任务。

• 超时 Promise 必须是 reject 行为（不能 resolve 一个特殊值），否则 await 会静默拿到它，掩盖真实失败原因
• 记得在 reject 前 clearTimeout，避免内存泄漏（虽然现代浏览器大多自动清理，但显式处理更可靠）
• 不要在 race 外再套一层 try/catch 来“兜底超时”，那样会模糊错误来源；超时错误就该在 catch 里明确识别和响应

fetch 场景优先考虑 AbortController，而非 race

fetch 原生支持 signal 选项，AbortController 能真正中止请求连接、释放 socket、停止数据传输。而 Promise.race 只是“放弃等待”，底层请求仍在后台运行，可能浪费带宽和服务器资源。

• 创建 controller 实例，传 signal 给 fetch，并在超时或用户取消时调用 controller.abort()
• fetch 拒绝时 error.name 会是 'AbortError'，可据此区分网络失败与主动中止
• 若需兼容旧环境（如不支持 AbortController 的 Node.js 版本），再回退到 Promise.race + timeout Promise 方案

在 async 函数里统一处理超时逻辑，别重复写 race

把超时包装抽成可复用函数，比如 withTimeout(promise, ms)，能让业务代码保持语义清晰，也方便后续加日志、监控或重试策略。

• 函数应返回新 Promise，不修改原 promise，确保调用方控制权完整
• 错误信息建议包含原始操作标识（如接口路径、参数摘要），便于排查哪次调用卡住了
• 避免在 withTimeout 内部做重试——重试是业务决策，应由上层 async 函数根据错误类型决定是否重发

注意错误捕获的粒度：超时 ≠ 全局失败

一次 await 抛出超时错误，不代表整个流程要终止。很多场景下，你可以降级处理：返回缓存、展示默认内容、记录异常后继续执行后续步骤。

• 在 catch 中判断 error.message 是否含 'timeout' 或 error.name === 'AbortError'，再分支处理
• 避免在顶层 try/catch 里吞掉所有错误，尤其是超时类错误——它们往往是系统压力或依赖服务异常的信号
• 如果多个并行请求都需要超时控制，用 Promise.allSettled + withTimeout 组合，比全用 race 更可控