容器重启策略配错会导致不重启或无限重启，关键在于选对类型：web服务用always，数据库用unless-stopped，批处理用no，worker用on-failure:5；须配合资源限制、healthcheck和退出码监控。

容器重启策略配错，不是不重启，就是无限重启——生产环境里最常踩的坑就在这儿。关键不在“设不设”，而在“设对没”：策略类型、触发条件、资源配合、日志可观测性，缺一不可。

重启策略选错：最典型误配场景

很多人把 always 当成“万能保险”，但其实它会在手动 stop 后自动拉起，导致运维停服务失败；而 unless-stopped 才是数据库、消息队列等需长期运行又允许人工干预的首选。

• web 服务（Nginx/API）：用 always，确保宿主机重启后自动恢复
• MySQL/PostgreSQL：用 unless-stopped，避免误操作后无法真正停机
• 批处理任务或数据迁移脚本：明确写 restart: no，防止失败后反复重试掩盖错误
• worker 类后台任务：用 on-failure:5，加 delay:10s 防雪崩，避免瞬时密集重启压垮依赖服务

策略生效但容器卡住不启动？查这三处

配置写了，docker ps -a 看到状态是 Exited (1)，但没立即重启——不是策略失效，而是被底层机制拦住了。

• Docker 守护进程负载高：执行 systemctl status docker 和 journalctl -u docker -n 20，看是否有调度延迟或 event queue 积压
• 容器启动耗时超默认超时：Docker 默认等待容器在 10 秒内进入 running 状态，否则标记为失败。若应用冷启慢（如 Java Spring Boot），需配合 healthcheck 或调整启动逻辑
• 资源争抢未显式限制：OOM Killer 杀进程后，on-failure 会触发，但若内存持续不足，新实例仍秒退。务必配 deploy.resources.limits.memory

验证与监控：不能只靠“看着像正常”

重启次数、退出码、健康状态，必须可量化。光看 docker ps 是盲人摸象。

Docker Image Puller

使用 Python 脚本下载 Docker 镜像并打包为 tar 文件。用户说“下载镜像”“拉取镜像”“pull xxx”“帮我下载 nginx 镜像”等时触发。支持 SOCKS5 代理直连（推荐）和国内镜像站加速两种模式。

下载

• 查最近一次退出码：docker inspect myapp --format='{{.State.ExitCode}}'
• 查累计重启次数：docker inspect myapp --format='{{.RestartCount}}'
• 查是否处于健康状态：docker inspect myapp --format='{{.State.Health.Status}}'（需定义 healthcheck）
• 结合日志定位根本原因：docker logs --since "10m" myapp | tail -20，重点搜 OOM、Connection refused、timeout

生产环境黄金配置标准（Docker Compose v3.8+）

这不是模板拼凑，而是经高频故障反推的最小安全集：

• 所有长期服务必须声明 restart，禁用默认 no 行为
• 数据库类服务统一用 unless-stopped，并挂载外部 volume，禁止使用匿名卷
• 每个服务必须配 healthcheck，且 start_period 要大于应用实际冷启时间
• 强制设置 deploy.resources：至少限定 memory，CPU 可选但建议设 cpus: "0.5" 防止单容器吃满核
• 日志统一配 logging.driver: "json-file" + options.max-size: "10m" + options.max-file: "3"

策略本身不复杂，但脱离资源约束、健康检查和可观测性，就是纸上谈兵。