不是所有异常都适合重试，更不是所有重试都安全；需根据异常类型区分可恢复（如网络超时、连接拒绝、503/504）与不可恢复错误（如400、401、409、业务终态码），并严格以接口幂等性为前提实施重试。
在分布式重试机制中，**不是所有异常都适合重试，更不是所有重试都安全**。盲目重试非幂等操作，会直接引发资损、数据重复或状态错乱。关键在于：**根据异常类型区分“可恢复”与“不可恢复”，再结合接口是否具备幂等性，决定是否允许重试**。
一、哪些异常类型原则上允许重试？
这类异常通常反映的是**临时性、外部性、非业务逻辑错误**，系统状态未被实质性改变，重试有较大概率成功且无副作用：
- 网络层超时（SocketTimeoutException、ReadTimeoutException）：请求已发出但未收到响应，下游服务可能已处理成功（如支付已扣款），也可能未处理。此时必须依赖幂等设计，才可安全重试。
- 连接拒绝/断连（ConnectException、IOException）：目标服务短暂不可达，属典型瞬时故障，重试合理。
- 限流/熔断触发（如Hystrix fallback、Sentinel BlockException）：说明服务端主动拒收，待流量回落或熔断恢复后重试有意义。
- HTTP 503 Service Unavailable、504 Gateway Timeout：网关或上游服务临时过载，非业务失败，适合指数退避重试。
二、哪些异常类型应禁止重试？
这些异常表明**业务已明确失败、状态已变更，或失败不可逆，重试只会放大问题：
- HTTP 400 Bad Request、401 Unauthorized、403 Forbidden：客户端参数错误、认证失效或权限不足，重试相同请求毫无意义，需前端修正或用户重新授权。
- HTTP 404 Not Found：资源不存在，比如订单号无效，重试无法凭空生成资源。
- HTTP 409 Conflict：常用于幂等校验失败（如请求ID已存在），说明该操作已被执行过，再次重试将违反业务约束。
- 业务自定义错误码（如“余额不足”“库存为0”“订单已关闭”）：属于终态业务拒绝，代表前置条件不满足，重试不会改变结果，反而可能干扰用户感知或触发风控规则。
三、如何把异常类型和幂等性联动起来做决策？
重试策略不能脱离幂等能力单独存在。一个安全的重试闭环必须满足两个前提：
- 调用方（重试发起方）识别异常类型，只对可恢复异常启动重试；
- 被调方（提供接口方）确保该接口对同一请求具备幂等性——即无论重试几次，最终业务状态一致（如支付接口：同一订单号+同一金额，多次调用只扣一次款）。
例如：支付回调接口收到第三方重复通知（HTTP 200），若后端未校验幂等（如未比对流水号+状态），直接执行扣款，就会导致重复扣款；而若该接口已通过唯一请求ID + Redis setIfAbsent 实现幂等，则即使收到10次重复通知，也仅执行一次真实扣款，其余全部快速返回成功响应。
四、实际落地建议
在代码或配置层面，需结构化管理异常分类与重试行为：
- 使用 Feign、Dubbo 或 Spring Retry 时，显式配置
retryableExceptions，只包含TimeoutException、IOException等可恢复类； - 对
RuntimeException子类做细粒度封装，如定义TransientNetworkException与BusinessRejectException，便于策略路由； - 日志中记录每次重试的原始异常类型、重试次数、请求唯一标识（X-Request-ID），便于事后追溯是“重试合理但失败”，还是“不该重试却重试了”；
- 监控告警中增加“重试率突增”指标，并关联异常类型分布，快速定位是下游抖动，还是上游误配了重试范围。
