Docker run 不支持 --restart-delay 参数，该参数仅存在于 Docker Compose 和 Swarm service 中；真实可用策略包括：① --restart=on-failure:N 限制重试次数；② 应用层实现指数退避；③ 配合健康检查与 --health-start-period 避免假启动；④ 编排场景下使用 restart_delay。
docker run 命令本身并不提供 --restart-delay 参数。这是常见误解——docker 官方 cli 中 没有 --restart-delay 这一选项，该参数并不存在于 docker run 或 docker create 的合法参数列表中。
真正控制重启间隔的机制，只在 Docker Compose（v2.23+） 和 Swarm service 模式 中通过 restart_delay（Compose）或 --restart-delay（docker service create）支持，且仅适用于“自动重启策略触发后的等待时间”，而非 docker run 场景。
所以，若你目标是：
✅ 降低故障容器频繁重启对系统 CPU、I/O、网络造成的脉冲式负载波动
✅ 避免雪崩式重试（如数据库未恢复时每秒重连）
✅ 让系统有喘息时间，提升整体稳定性
你需要绕过“不存在的 --restart-delay”，改用以下真实可用、生产验证有效的组合策略：
✅ 1. 用 --restart=on-failure + --restart-max-attempts 控制重试频次
避免无节制重启，防止资源耗尽：
docker run -d \ --name api-service \ --restart=on-failure:5 \ # 仅非零退出时重启，最多5次 --restart-unless-stopped \ # （可选）补充兜底，但不替代上条逻辑 -e DB_HOST=db \ myapp:prod
⚠️ 注意：
on-failure:N是唯一能限制重试次数的原生命令行参数；always或unless-stopped不支持退避延迟，会立即重启，极易引发抖动。
✅ 2. 在应用层实现指数退避（最可靠、最推荐）
Docker 不管你的业务逻辑是否就绪。真正的负载波动源头，常是容器内进程反复失败重试（如 Java 应用每 200ms 连 DB，连不上就崩溃 → 触发 Docker 重启 → 再连…死循环）。
✅ 正确做法：让应用自己处理失败，并延迟重试：
# Python 示例：启动脚本中加入退避逻辑
import time
import random
import sys
for attempt in range(1, 6):
if connect_to_db(): # 自定义健康检查
break
wait = min(2 ** attempt + random.uniform(0, 1), 30) # 指数退避，上限30秒
print(f"DB not ready, retrying in {wait:.1f}s (attempt {attempt}/5)")
time.sleep(wait)
else:
sys.exit(1) # 彻底放弃✅ 效果：容器只启动 1 次，内部重试带退避，Docker 不感知失败，零重启抖动，CPU/I/O 波动平滑。
✅ 3. 用健康检查 + start_period 避免“假启动”触发连锁重启
很多容器“已运行”但业务不可用（如 Spring Boot 启动完成但 Actuator /health 返回 503），导致依赖它的服务立刻失败 → 级联重启。
加 --health-start-period 给应用冷启动留足时间：
docker run -d \ --name user-service \ --health-cmd="curl -f http://localhost:8080/actuator/health || exit 1" \ --health-interval=10s \ --health-timeout=5s \ --health-start-period=60s \ # 启动后60秒内不判定失败 --health-retries=3 \ user-service:1.2
✅ 效果：避免容器刚拉起就被标记 unhealthy → 被 orchestration 工具（如 Swarm/K8s）误判驱逐，间接减少无效重启。
✅ 4. 若必须用 Compose 或 Swarm：才启用 restart_delay
仅当使用编排工具时，该参数才生效：
# docker-compose.yml
services:
frontend:
image: nginx:alpine
restart: on-failure
deploy:
restart_policy:
condition: on-failure
delay: 10s # ← 这才是真正的 restart_delay（单位：s/ms）
max_attempts: 3
window: 120s⚠️ 注意：
delay是两次重启尝试之间的最小间隔，不是随机抖动；如需防同步风暴，需配合window和max_attempts使用。
不依赖虚构参数，靠组合控制重试边界、把退避逻辑下沉到应用、用健康检查锚定真实就绪态——这才是应对负载波动的务实路径。
