应仅对网络层异常（如TypeError、status=0）和临时服务端错误（5xx、429、408）重试，避免重试4xx客户端错误；需在catch中细粒度判断、用AbortController控制生命周期，并添加抖动防雪崩。
不是所有请求失败都该重试，盲目重试 401、404 或参数错误反而浪费资源、掩盖问题。关键在于精准识别“值得重试的网络错误”，再触发重试逻辑。
只对网络层异常和部分服务端错误重试
真正适合重试的错误集中在两类：一类是 fetch 根本没收到响应（网络中断、超时、连接拒绝），另一类是服务器明确表示“暂时不可用”（如 503、504、部分 429）。这些错误通常具有临时性。
-
网络层错误：捕获
TypeError（消息含 "Failed to fetch"、"NetworkError"、"AbortError" 等），或 fetch 返回的response.status === 0（常见于 CORS 失败或离线） -
服务端临时错误：检查
response.status，仅对500–599、429（限流）、408（请求超时）等状态码重试；跳过400–403、404、410等客户端错误
在 catch 中做细粒度判断
不要一捕获就重试。应在 catch 块里先分析错误类型和响应状态，再决定是否进入重试流程。
- 如果是
TypeError，大概率是网络问题，可重试 - 如果拿到
Response对象但!res.ok，进一步判断res.status是否属于 5xx 或特定临时码 - 可封装一个
isRetryable(error, response)函数，统一返回布尔值，便于复用和测试
配合 AbortController 防止无效重试
用户可能已离开页面或取消操作，此时继续重试毫无意义，还可能引发内存泄漏。
立即学习“Java免费学习笔记（深入）”；
- 每次请求都传入
signal，并在重试前检查signal.aborted - 若已中止，直接 reject，不执行延迟、不发起下一次请求
- 确保整个重试链可被外部控制，比如在 React 组件卸载时调用
abort()
加抖动避免集群共振
大量客户端在同一时刻重试，容易造成后端雪崩。简单加随机偏移就能显著缓解：
- 计算基础延迟后，乘以
0.5 + Math.random() * 0.5（即 0.5–1.5 倍抖动） - 例如指数退避算出 1000ms，实际等待可能是 632ms 或 1478ms，打散重试时间点
