重试需要停止条件

一次请求失败后再试一次，听起来是简单的可靠性改进。但当客户端和服务端都自动重试时，一次故障可能变成多轮请求；如果上游已经很忙，增加的流量反而会让它更难恢复。重试不是“遇到错误就再来一次”，而是一种有成本的恢复策略。

首先要问这类失败是否可能短暂。网络连接重置、服务端明确表示暂时不可用，通常值得考虑重试；输入校验失败、权限不足或固定的资源不存在，重复相同请求不会改变结果。对于返回 Retry-After 的服务，应尊重它给出的等待时间，而不是让客户端继续密集请求。

限制次数，也限制总时间

为自动重试设置最大次数和整体截止时间。逐步增加等待间隔可以减少瞬时压力，加入少量随机抖动则能避免许多客户端在同一时刻一起再次请求。达到上限后，应把控制权交还给界面或用户，而不是悄悄在后台无限循环。

单个请求的超时也不等于整条操作的截止时间。若每次尝试都允许等待很久，即使重试次数有限，总等待仍可能超出用户预期。系统可以在开始时确定一个总预算，再由剩余时间决定是否还有空间进行下一次尝试。

先确认重复执行是否安全

读取数据一般较容易重试；写入、扣款或创建资源则需要更谨慎。请求超时并不代表服务端没有完成操作：客户端可能只是在响应到达前断开。如果此时原样再发一次，可能创建两条记录或重复执行副作用。

对需要安全重试的写操作，可以使用幂等键或服务端去重记录，让同一个逻辑操作重复抵达时只产生一次结果。若系统无法提供这类保证，界面应先查询操作状态，或清楚提示用户当前结果未知，而不是假定它失败了。

把最终状态交还给调用者

重试结束后，调用者需要知道请求成功、明确失败，还是结果仍然未知。记录尝试次数、间隔、最终状态和受控错误类别，也有助于发现重试是否正在掩盖上游故障。日志无需保存敏感正文，策略也不该只靠一次成功的偶然结果来判断。

良好的重试策略为短暂故障留出恢复机会，同时清楚知道何时停止。次数、总时长、错误类别和幂等性，构成了这条边界。