容器生命周期问题关键在看懂五种核心状态：created（已创建未启动）、exited（启动即退出）、restarting（反复重启）、paused（进程冻结）、dead（异常死亡）；Running仅表示主进程存活，不等于服务健康。

容器生命周期出问题，往往不是“起不来”就是“活不久”。关键不在命令记多少，而在状态看懂没、日志读对没、资源配准没。

看清五种核心状态，别被 running 蒙蔽

容器显示 running 只代表主进程（PID 1）还在，不代表服务能响应请求。真正要盯的是这五个状态：

• created：容器建好了但没启动，常见于 docker create 后忘记 start，或镜像缺少入口命令
• exited：启动即退出，90% 是入口命令执行完就结束（比如用 alpine:latest 运行 echo hello），或应用崩溃
• restarting：反复重启，大概率是健康检查失败、OOM 被杀，或 --restart=on-failure 触发了自动重试
• paused：进程被冻结，内存保留但不占 CPU，适合临时释放资源，用 docker unpause 可秒级恢复
• dead：极少见，通常因 Docker 守护进程通信中断或宿主机异常导致，需查 journalctl -u docker

日志和 inspect 是第一现场

容器异常，先别删、别重启。用只读命令锁定线索：

Docker Encyclopedia

Docker 文档优先工作流：针对 Docker 特定问题、故障排除、命令规划、镜像/构建、容器/运行时操作及 Compose 等

下载

• docker logs --tail 100 <id></id>：看最后 100 行输出，重点找 panic、Connection refused、OOMKilled 等关键词
• docker inspect <id> | jq '.State'</id>：查看完整运行时状态，确认 Status、ExitCode、OOMKilled 是否为 true
• docker stats <id></id>：实时看内存/CPU 占用，若内存曲线冲顶后骤降，基本可断定是 OOM 终止

资源限制与健康检查必须协同调优

单设内存 limit 或单配健康检查，都容易埋坑：

• 内存超限：用 -m 512m 限制，但别禁用 OOM Killer（--oom-kill-disable）除非你真有把握——否则容器卡死比退出更难排查
• 健康检查误判：HTTP 探针设置太激进（如 --interval=5s），应用冷启动慢就会被反复重启；建议 initialDelaySeconds 设为启动耗时的 2 倍以上
• 启动失败兜底：加上 --restart=unless-stopped 或 --restart=on-failure:3，避免一次失败就彻底离线

清理与隔离：让问题不扩散

故障容器堆着不处理，会拖慢整个 Docker 系统：

• 删已停容器：docker rm $(docker ps -aq -f status=exited)
• 清无用镜像：docker image prune -f --filter "until=48h"，防磁盘爆满引发 no space left on device
• 调试不依赖原容器：用 docker run -it --rm --entrypoint /bin/sh your-image 启一个干净 shell，验证脚本、权限、路径是否正常