Docker容器重启策略由--restart参数控制，共四种：no（不重启）、on-failure[:max-retries]（仅非0退出码重试）、always（任何退出均重启）、unless-stopped（除手动stop外均重启），需配合-detached模式及健康检查提升可靠性。
直接用 docker run 指定重启策略，核心就靠 --restart 参数。它不是“启动后自动重试”的开关，而是告诉 Docker 守护进程：当容器退出时，按什么规则决定要不要拉起来——这个逻辑在宿主机重启、Docker 守护进程重启、甚至容器自己崩溃时都生效。
四种策略的行为差异
每种策略对应不同的退出响应逻辑，关键看容器退出状态码（0 表示正常退出，非 0 通常表示异常）：
- no：默认值。无论容器怎么退出（哪怕刚启动就崩了），Docker 都不干预。适合调试、一次性任务或由外部编排工具统一管理的场景。
-
on-failure[:max-retries]：只对非 0 状态码响应。加数字（如
on-failure:3）表示最多重试 3 次；不加则无限重试。注意：如果容器正常退出（状态码 0），哪怕你希望它一直跑，也不会重启。 -
always：只要容器退出，不管状态码是 0、1 还是 127，一律重启。连
docker stop后 Docker 守护进程重启，它也会跟着起来。容易引发启动即失败的死循环，需配合健康检查使用。 -
unless-stopped：最常用也最稳妥。和
always类似，但多一个前提——如果容器在 Docker 守护进程启动前就被手动docker stop过，那之后就不会自动拉起。适合数据库、API 服务等长期运行的关键组件。
常见误操作与避坑点
策略看似简单，但几个细节常被忽略：
- 容器必须以
-d（detached 模式）运行，--restart才有效。前台模式（如docker run nginx）不适用该机制。 - 状态码 125/126/127 属于 Docker 自身执行错误（如镜像不存在、命令不可调用），
on-failure会响应，但unless-stopped默认不处理这些码——实际行为取决于 Docker 版本，建议测试验证。 - 已运行的容器不能直接改
--restart，要用docker update --restart=xxx 容器名。修改后无需重启容器，策略立即生效。 - 不要混淆
docker restart 容器名（手动触发一次重启）和--restart（自动恢复策略），后者是持久化配置，前者只是即时操作。
怎么查和验证当前策略
运行中或已停止的容器，都能快速确认它的重启设置：
- 查策略：
docker inspect -f "{{.HostConfig.RestartPolicy.Name}}" 容器名，输出就是no、always等字符串。 - 查退出原因：
docker ps -a看最后一列，例如Exited (1) 2 hours ago，括号里的1就是退出码，结合策略就能判断是否该重启。 - 模拟验证：用
docker kill -s SIGTERM 容器名或让应用主动退出，观察是否按预期拉起。
组合健康检查更可靠
单靠重启策略不够智能。比如容器卡住但没退出，Docker 不会感知。建议搭配 --health-cmd 使用：
- 例如：
docker run -d --restart=unless-stopped --health-cmd="curl -f http://localhost:80 || exit 1" --health-interval=30s nginx - 这样 Docker 不仅看“是否退出”，还会定期探测服务是否真可用。若连续失败，可触发重启，形成真正自愈闭环。
