应捕获特定网络异常而非Exception：requests对应ConnectionError、Timeout、HTTPError（需status_code≥500）；httpx对应ConnectError、TimeoutException；重试3次，采用带抖动的指数退避；必用functools.wraps保留签名；非幂等请求如POST需业务层控制重试。
重试装饰器该用哪个异常类型捕获
直接捕获 Exception 会吞掉你本该立刻发现的 bug，比如拼错变量名抛的 NameError，或者传了错误参数导致的 TypeError。真正该重试的只有网络层不稳定的错误：连接断开、超时、服务端临时 5xx。Requests 库里对应的是 requests.exceptions.ConnectionError、requests.exceptions.Timeout、requests.exceptions.HTTPError（需手动检查 status_code ≥ 500）。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 不要写
except Exception:，宁可漏重试，也不掩盖逻辑错误 - 对
HTTPError做二次判断：if e.response.status_code >= 500:再重试 - 如果用了
httpx，对应异常是httpx.ConnectError、httpx.TimeoutException
retry_times 和 delay 怎么设才不被封又不白等
重试不是越多越好，3 次是常见安全值；间隔也不能固定，否则大量请求会在同一毫秒撞上目标服务器——容易触发频率限制。必须用指数退避（exponential backoff），比如第一次等 1s，第二次等 2s，第三次等 4s，再加点随机抖动（jitter）。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 默认从
retry_times=3起手，观察日志里失败率再调 - 延迟用
min(60, (2 ** attempt) + random.uniform(0, 1))，上限卡死 60 秒防雪崩 - 别在重试里无脑加
time.sleep(1)，那只是“假装重试”，没解决并发冲突问题
装饰器怎么透传原始函数的签名和文档
用 functools.wraps 是底线操作。否则调试时看到的函数名是 wrapper，IDE 提示参数全丢，help(request_with_retry) 显示空文档——查问题时你会多花三倍时间。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 每写一个装饰器，第一行就写
from functools import wraps，第二行就套@wraps(func) - 如果函数有 type hint（比如
def fetch(url: str) -> dict:），@wraps会自动保留，不用额外处理 - 别自己手动复制
__name__和__doc__，出错概率高还难维护
重试期间如何避免重复提交表单或修改状态
GET 请求天然幂等，重试安全；但 POST/PUT/DELETE 不是。如果第一次请求其实成功了，只是响应没收到，重试就会造成数据重复或误删。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 对非 GET 方法，先确认接口是否支持幂等性（比如带
Idempotency-Keyheader） - 没有幂等保障时，别在装饰器里自动重试 POST，改用业务层显式控制（例如先查再发）
- 日志里必须记录每次重试的请求 method + url + body hash，方便事后排查重复动作
重试最麻烦的从来不是写几行代码，而是得想清楚：这次失败，到底是真失败，还是“看起来失败”——而这个判断，没法交给装饰器自动做。
