Python 脚本的重试设计：什么时候该重试，什么时候必须停

重试是自动化脚本里最容易被滥用的能力。很多脚本的第一版都是这样写的：出错就重来，最多三次。看起来稳妥，实际上经常把一次小故障放大成大问题，尤其是操作本身不幂等的时候。

一、先判断这次操作能不能重试

可以重试的典型是"读"：查状态、拉列表、取一个资源。失败通常来自网络抖动或服务端瞬时过载，重来一次的代价几乎为零。

不能直接重试的是"写"：下单、扣款、提交表单、创建资源。请求超时不代表服务端没执行，盲目重试可能产生两笔订单、两条记录。这类操作要先设计幂等键，或者先查一次"到底成没成"。

二、区分错误类型，别把所有异常都当网络问题

值得重试的：连接超时、连接被重置、502/503/504、限流（429，且响应里给了 Retry-After）。

不该重试的：401/403（凭据或权限问题，重试一万次也一样）、400（参数错了）、404（资源不存在），以及业务层返回的"余额不足"这类确定性失败。把不该重试的错误塞进重试循环，只会让日志更难读，还会拖长故障时间。

三、退避要有上限，也要有抖动

固定间隔重试会让所有客户端在同一秒回来，把刚恢复的服务再打挂。常用做法是指数退避加随机抖动，例如 1 秒、2 秒、4 秒，每次再乘一个 0.5 到 1.5 的随机系数；同时设一个总时长上限，超过就放弃并告警。

重试次数不是越多越好。三次通常够用，超过五次基本说明问题不在抖动，而在配置或依赖。

四、给重试留下证据

每次重试都记一行日志：第几次、什么错误、等了多久。没有这些信息，事后只能看到"失败了"，无法判断是重试策略不对，还是依赖真的挂了。

如果脚本要长期无人值守，最好再加一个"连续失败计数"：连续多轮都失败时，主动停下来通知人，而不是安静地空转。

一句话总结：重试的价值不在于"多试几次"，而在于把偶发故障和确定性故障分开处理。前者值得等一等，后者越早暴露越好。