标准答案
- 连接失败、短暂服务不可用和部分限流可能适合有限重试，但要有退避、抖动和总截止时间。
- 参数错误、鉴权失败、资源不存在、业务冲突和已知不可恢复错误通常不应重试。
- 支付、扣款、发券等操作即使网络超时也不能直接重试，应使用幂等键和状态查询。
- 重试次数、成功率、放大倍数和下游容量要纳入监控与熔断。
题目解析
一次失败被重试后，系统实际收到的工作量可能成倍增加；当下游已经过载时，重试会进一步占用连接和线程，形成失败反馈。因此重试是容量设计的一部分，不是单纯的容错开关。
可以考虑重试的通常是短暂网络失败、连接建立失败和部分限流，但仍需退避、抖动、最大次数和总 deadline。参数错误、鉴权失败、资源不存在和业务冲突一般应立即返回。
写操作的网络超时不能证明服务端没有执行。幂等键、唯一约束、状态查询和结果回查要先于自动重试设计，尤其是支付、扣款、发券和消息发布。
常见误区
- 误区：所有 5xx 都重试。改正：按错误是否暂时、操作是否幂等、剩余预算和下游容量分类处理。
- 误区：每一层客户端各自重试。改正：确定一个负责重试的层，其他层传递截止时间，避免乘法放大。
- 误区：重试成功就等于原请求只执行一次。改正：成功只能说明这次返回成功，仍需依靠幂等记录或业务状态确认副作用次数。