应仅对网络层错误和5xx服务端错误重试：前者如err_network、超时中断等，后者如503/504等可自愈场景；4xx客户端错误及非幂等请求（如无idempotency-key的post）不可重试。
判断哪些错误该重试，核心是区分“临时性故障”和“永久性错误”。移动端网络波动、服务端瞬时过载这类问题往往只需一次重试就能恢复；而参数错、未登录、资源不存在等问题，重试毫无意义，还可能引发重复提交或误导用户。
只对网络层错误和 5xx 服务端错误重试
这两类错误具备“临时性”特征，重试成功率高：
- 网络层错误：浏览器报出的 ERR_NETWORK、ERR_CONNECTION_TIMEOUT、ERR_CONNECTION_REFUSED、ECONNABORTED（超时中断）等，代表请求根本没发出去或中途断开，不是业务逻辑问题；
- 5xx 状态码：500（内部错误）、502（网关错误）、503（服务不可用）、504（网关超时）——尤其 503/504 常见于服务器扩容、负载均衡切换、上游依赖延迟等可自愈场景；若响应头含 Retry-After，说明服务端明确建议等待后重试。
明确排除 4xx 客户端错误
4xx 表示请求本身有问题，重试只会重复失败：
- 400：参数格式错误或缺失，需前端校验修复；
- 401 / 403：身份失效或权限不足，应跳转登录或提示授权；
- 404：路径不存在，大概率是前端路由或接口配置错误；
- 422：语义错误（如表单验证不通过），需反馈具体字段问题。
特别注意非幂等请求的限制
对 POST、PUT、DELETE 等可能改变服务端状态的请求，不能盲目重试：
- 比如 POST /api/order 创建订单，首次失败后若直接重试，可能生成两笔相同订单；
- 只有服务端支持幂等机制（如要求携带 Idempotency-Key 请求头），才可安全重试；
- 否则，这类请求失败后应交由用户确认是否重发，或降级为本地缓存+异步提交。
实际判断时建议结合响应体与错误对象
光看 status 不够可靠，要综合判断：
- fetch 或 axios 返回的 error 对象中，err.name === 'AbortError' 或 err.code === 'ERR_NETWORK' 属于可重试网络异常；
- 响应 status 为 0（如 CORS 阻止、跨域失败）或未定义，通常也属于网络中断，可重试；
- 若服务端在 5xx 响应体中返回 { "code": "SERVICE_BUSY" } 这类标识，比单纯看 status 更精准，建议在 shouldRetry 函数里解析 body 判断。
