容器显示 Exited 状态说明主进程已终止，需通过退出码（如137为OOM、143为SIGTERM）、日志和启动命令排查；CMD/ENTRYPOINT须前台长期运行；重启策略需结合内存限制与健康检查使用。
容器显示 Exited 状态，说明它已终止运行，不是卡住也不是暂停，而是进程主动退出了。根本原因通常是主进程（PID 1）执行完就退出，或启动失败、崩溃、被系统杀死。排查需从日志、退出码、启动命令三方面入手；自动重启则依赖 Docker 的重启策略，但必须理解其适用边界。
查看退出码和日志定位根本原因
退出码是关键线索：
- 0：正常退出——检查是否应用设计为单次运行（如脚本、批处理任务），并非故障；
- 1–127：应用内部错误（如配置错误、连接失败、panic）；
- 137：被 SIGKILL 终止——大概率是 OOM（内存超限）被内核 kill；
- 143：被 SIGTERM 正常终止——可能是手动 stop、docker-compose down 或健康检查失败触发重启策略干预。
立即执行以下命令获取信息：
docker inspect | grep -i "status\|exitcode"docker logs
若日志为空，说明进程秒退——尝试加 -it 参数以交互方式运行镜像，观察启动瞬间的报错（例如缺少环境变量、挂载路径不存在、端口被占）。
检查 CMD/ENTRYPOINT 是否符合容器长期运行要求
Docker 容器生命周期绑定主进程（PID 1）。如果 CMD 执行的是短命令（如 bash -c "echo hello" 或 python script.py），脚本结束，容器立刻 Exited。
- Web 服务需前台运行：用 gunicorn --bind 0.0.0.0:8000 --workers 2 app:app，而非后台启动（&）；
- 避免使用 systemctl、service 启动服务——容器无 init 系统支持；
- 调试时可在 CMD 末尾加 tail -f /dev/null 保活（仅临时验证，非生产方案）。
合理配置 restart 策略实现自动恢复
restart 策略在容器退出后由 Docker daemon 触发，不依赖进程自身逻辑。常用值：
- --restart=no：默认，不重启；
- --restart=on-failure[:max-retries]：仅当非 0 退出码时重启，可设最大重试次数（防死循环）；
- --restart=always：无论退出码如何都重启（包括手动 docker stop）；
- --restart=unless-stopped：同 always，但跳过因 docker stop 停止的容器——适合守护类服务。
注意：always 和 unless-stopped 在容器因 OOM（退出码 137）退出后会立即重启，可能反复触发 OOM ——务必先通过 -m 限制内存，再配重启策略。
补充建议：用 healthcheck 主动发现异常
仅靠 restart 策略不够智能。添加健康检查可让 Docker 更早感知“活着但不可用”的状态：
HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \CMD curl -f http://localhost:8080/health || exit 1
配合 --restart=on-failure，健康检查连续失败也会触发重启。运行中可用 docker ps 查看 STATUS 列中的 (healthy) 或 (unhealthy) 状态。
