把重试写清楚：接口失败时的三层策略

调用外部接口失败时，最常见的错误不是不重试，而是无差别重试。网络抖动、对方限流、服务短暂不可用，本质不同，处理方式也不该相同。把重试当成默认兜底，只会把一次失败放大成多次冲击，甚至把下游压垮。

第一层是区分错误。超时和连接中断可以重试，因为请求可能根本没有到达；明确的业务错误不应该重试，例如参数非法、权限不足、余额不足，重试多少次结果都一样。限流和服务端临时错误介于两者之间，需要等待后再试，而不是立刻再发。

第二层是控制节奏。固定间隔重试容易在故障恢复瞬间形成惊群效应，大量客户端同时涌入。指数退避加随机抖动是更稳妥的做法：第一次等一秒，第二次等两秒，第三次等四秒，再各自加一点随机值，把请求打散。重试次数也要设上限，通常三到五次就够了，超过这个次数，继续重试的收益很低。

第三层是保证幂等。重试最大的风险是重复执行：扣款发了两次，订单建了两条，消息投递了两遍。解决办法是在请求里带一个稳定的幂等键，服务端用它去重；或者把操作设计成天然幂等，例如用唯一订单号创建资源，重复提交返回第一次的结果。没有幂等保障的写操作，宁可让人工介入，也不要自动重试。

还有一个容易忽略的点，是重试的边界。不是所有环节都适合在调用方重试。网关层可以对瞬时故障做一次快速重试，业务层再决定是否做有退避的重试，而跨服务的长链路重试必须设置总超时，避免一次用户请求在内部循环很久。每一层都重试，等于把次数相乘。

熔断是重试的刹车。当错误率持续升高、连续失败达到阈值时，先停下来，直接返回降级结果或友好提示，等一段时间再放少量请求探路。探路成功再恢复，失败继续熔断。这比让每个请求都走满重试流程更能保护系统，也能给故障恢复留出时间。

落地时可以给重试写一张清单：错误类型是否可重试、最多几次、间隔怎么算、幂等键有没有、总超时是多少、失败后记什么日志。日志里至少要包含请求标识、重试次数、每次失败原因，方便事后复盘。重试不是越多越好，而是在该停的时候停得住，在该试的时候试得稳。