应采用“指数退避+随机抖动+失败分类+超时保护”四合一重试函数：基础间隔100ms～500ms，倍数为2，每次休眠时间=base×2^attempt×(1±0.3)，最大重试6～8次，总耗时≤3分钟；仅对5xx、连接超时等临时错误重试，跳过4xx等永久错误；加timeout限制总耗时，用flock防并发，记录详细日志并自动归档失败响应。
在网络抖动场景下，Shell脚本不能靠简单循环+固定sleep硬扛——那样容易集体重试、撞上抖动峰值、触发限流甚至压垮目标服务。真正可用的方案是把“指数退避 + 随机抖动 + 失败分类 + 超时保护”四者打包进一个可复用的重试函数。
核心：写一个带 jitter 的指数退避重试函数
直接用 sleep 1; sleep 2; sleep 4 是危险的。必须引入随机性（jitter），让每次重试时间在理论值上下浮动 30%～50%，避免多个任务同步冲击。
- 基础间隔设为 100ms～500ms（太短没错峰效果，太长拖慢恢复）
- 退避倍数用 2（即 0.2s → 0.4s → 0.8s → 1.6s…）
- 每次 sleep 时间 =
base * (2 ** attempt) * (1 ± random_factor)，推荐 random_factor 取 0.3 - 最大重试次数建议 6～8 次，总耗时控制在 2～3 分钟内
只对可重试错误重试，跳过永久性失败
不是所有失败都该重试。比如 curl 返回 curl: (7) Failed to connect 或 timeout 属于典型网络抖动，可重试；但返回 400 Bad Request 或 401 Unauthorized 就不该再试——重试只会重复报错。
- 用
curl -s -w "%{http_code}" -o /dev/null获取状态码，再判断是否在 5xx 范围 - 检查 stderr 输出是否含
"Connection refused"、"Operation timed out"、"Network is unreachable" - 对关键操作（如上传文件、提交订单），重试前先用轻量请求查状态，确认不是业务侧已成功
加超时和资源隔离，防止单次卡死拖垮整条流水线
一次 hang 住，可能让定时任务堆积、锁文件残留、临时目录占满磁盘。
- 给整个重试块加硬性超时：
timeout 120s bash -c 'retry_upload'（限制总耗时 2 分钟） - 每次重试生成唯一 ID：
run_id=$(date +%s)-$$，日志、临时文件、锁路径都带上它 - 用
flock锁住关键资源，防止同一任务被多个实例并发执行：flock -n /tmp/upload.lock -c "curl ..."
记录过程、暴露状态，方便人工介入
重试不是黑盒。每次尝试要记清时间、耗时、错误原因、HTTP 状态码或 exit code，失败后自动归档原始响应体。
- 日志格式示例：
[2026-07-21T09:15:22] attempt=3, delay=1.24s, code=0, error="Connection timeout" - 连续 3 次失败且间隔趋近上限（如都 >1.5s），自动标记为 “疑似永久失败”，停止重试并发告警
- 失败时把 curl 的
-v输出截取前 20 行存入/var/log/retry_failures/${run_id}.log
