javascript中定时器实现网络请求超时控制的核心是用settimeout构建倒计时拒绝者，与fetch promise参与promise.race竞争；需搭配abortcontroller真正终止请求，并封装为timeout(promise,ms)函数，超时阈值应分层设定。
JavaScript 中定时器在处理网络请求超时控制，核心是用 setTimeout 构建一个“倒计时拒绝者”，让它和真实请求一起参与 Promise.race 竞争——谁先结束（fulfilled 或 rejected），就采用谁的结果。这不是魔法，而是明确的资源协调策略：前端不等、不卡、不假死。
定时器如何与 fetch 配合实现超时判断
原生 fetch 没有内置 timeout 参数，必须靠定时器补位。关键在于让定时器在超时后主动 reject，而非 resolve；否则 Promise.race 会误认为“成功完成”，掩盖真实失败。
- 创建一个仅用于超时的 Promise：用
setTimeout延迟调用reject(new Error('timeout')) - 将这个 Promise 和
fetch(...)Promise 一起传入Promise.race([...]) - 一旦定时器先触发，整个 race 就立即 reject，后续逻辑可统一捕获超时错误
- 注意：此时 fetch 请求仍在后台运行，只是前端不再关心它的结果
为什么必须搭配 AbortController 才算真正可靠
单纯靠 Promise.race + setTimeout 只能中断“等待逻辑”，不能终止网络连接本身。尤其在移动端或弱网下，未中止的 fetch 会持续占用 TCP 连接、消耗内存，甚至干扰后续请求。
- 创建
AbortController实例，把它的signal传给fetch选项 - 当定时器触发时，立刻调用
controller.abort()，底层请求会被浏览器真正取消 - 同时仍需
reject超时错误，确保上层业务能响应状态变化 - 务必在请求完成或失败后调用
clearTimeout，避免内存泄漏
封装成可复用的 timeout 函数
把重复逻辑抽出来，避免每次手写 race 和 timer。一个健壮的封装应支持任意 Promise，且每次调用都新建定时器，防止实例复用导致误触发。
- 函数签名建议为
timeout(promise, ms)，返回一个新的 Promise - 内部用
new Promise((_, reject) => {...})创建超时 Promise，不可 throw - 返回
Promise.race([promise, timeoutPromise]) - 若用于 fetch，建议再包一层，自动注入
AbortSignal并处理 abort 后的错误类型
超时时间设置不是越短越好
超时阈值要兼顾稳定性与体验。设得太短，容易在网络抖动时误判；设得太长，用户感知卡顿。实际中推荐分层设定：
- 读接口（如列表加载）：3–5 秒，配合骨架屏降低焦虑感
- 写接口（如提交订单）：8–12 秒，因涉及服务端校验与事务
- 可结合
navigator.connection.effectiveType动态调整（如 2g 网络延长至 15 秒） - 对重试请求，采用指数退避：第 1 次 3s，第 2 次 6s，第 3 次 12s
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
