fetch原生不支持timeout配置是设计选择，它忽略timeout字段、无内置超时机制、依赖网络栈兜底（如Chrome约300秒）、需手动结合AbortController实现超时控制，且对5xx错误码不reject，易致逻辑误判。

fetch 原生不支持 timeout 配置，这不是疏漏，而是设计选择——它把“何时中止”交给开发者控制，而非内置硬性超时逻辑。识别这个缺陷，关键不是看它“缺什么”，而是看它“不做什么”以及“做了什么却容易被误用”。

它根本不解析 timeout 字段

很多开发者习惯写：

fetch('/api', { timeout: 5000, signal }) // ❌ 完全无效

浏览器会静默忽略 timeout 字段，既不报错也不生效。这是因为 fetch 的 init 对象规范里压根没定义 timeout 这个键；传了等于白传，请求照发、永不自动中断。

它默认无超时上限，依赖底层协议或浏览器兜底

fetch 没有内置计时器，它的“超时”实际由网络栈决定：

• Chrome 通常在 300 秒（5 分钟）后终止挂起连接
• Firefox 约为 90 秒
• 这些值不可配置，且因平台、代理、HTTPS 握手状态而浮动
• 用户等待 2 分钟才看到失败，体验已严重受损

它把取消权交给 AbortController，但不自动关联时间

AbortController 是“开关”，不是“定时器”。你必须手动：

• 创建 controller 实例
• 用 setTimeout 调用 controller.abort()
• 确保 signal 正确传入 fetch 选项
• 记得 clearTimeout 避免内存泄漏（尤其请求提前完成时）

漏掉任一环，就等于没实现超时——比如只传 signal 却不触发 abort()，请求依然永不出错。

它对 HTTP 错误码保持沉默，加剧超时误判

fetch 在收到 504 Gateway Timeout 或 503 Service Unavailable 响应时，仍会 resolve Promise，不会 reject。这意味着：

• 你以为请求“成功返回了”，其实服务端早已放弃处理
• 前端未做 response.ok 或状态码校验，就会把超时响应当正常数据用
• 表面看没卡住，实则逻辑出错，更难定位