退出码来自容器本身，Docker Desktop仅是UI层；docker ps -a可快速查看全量容器状态及退出码，docker inspect -f '{{.State.ExitCode}}'能精准提取数字，配合.State.Error和docker logs -t等命令交叉验证原因。
退出码不是 Docker Desktop 特有的概念，它来自容器本身；Docker Desktop 只是 UI 层，真正要查的还是 docker CLI 的输出。 你看到容器在 Dashboard 里显示 Exited (137)，那个数字就是退出码，但 UI 不会告诉你它为什么是 137 —— 这得靠命令行补全判断依据。
docker ps -a 是最直接的退出码入口
Dashboard 上只显示状态和退出码，不显示时间、错误原因或完整命令。而 docker ps -a 会列出所有容器，STATUS 列里明确写着 Exited (127) 或 Restarting (42) 这类信息，一眼就能扫出异常容器。它比点开每个容器看详情更快，尤其当你有多个容器时。
- 退出码出现在 STATUS 列末尾括号内，比如
Exited (0)、Exited (139) - 如果容器刚退出，
FinishedAt时间戳能帮你确认是不是“秒退”——比如创建后 2 秒就 Finished，基本排除初始化耗时问题 - 别只盯着 Dashboard 的“最近运行”列表，它可能自动隐藏已退出容器；
docker ps -a才是全量视图
docker inspect -f '{{.State.ExitCode}}' 快速提取纯数字
当你写脚本或批量检查时，docker inspect 的 JSON 输出太冗长，-f 模板可以只取关键字段。比如你怀疑某容器内存超限，想快速确认是不是 137：
docker inspect -f '{{.State.ExitCode}}' my-app
输出就是 137，没有多余字符，方便后续用 if 判断或管道进其他命令。注意：如果容器还没创建成功（比如 docker run 报错没生成容器），这条命令会报错，说明问题不在“退出”，而在启动前就被 Docker 拒绝了。
-
.State.ExitCode是真实退出码，哪怕容器已删除，只要还在docker ps -a里，它就有效 -
.State.Error值得顺手一起查，比如输出OOMKilled: true或invalid argument in volume specification，比退出码更直白 - 别用
docker inspect my-app | grep ExitCode，容易匹配到日志或镜像层里的干扰项
docker logs 看不到输出？可能是进程根本没跑起来
很多人执行 docker logs my-app，发现空空如也，就以为“没日志”，其实更可能是主进程压根没执行到打印那一步。比如退出码是 127（命令未找到），意味着 CMD ["start.sh"] 里的 start.sh 文件不存在，Shell 连解释器都没进去，自然没 stdout。
- 如果
logs完全空白，且退出码是126（权限拒绝）、127（找不到命令）或1（启动失败极快），优先检查镜像内容和启动命令路径 - 加
-t参数看带时间戳的日志：docker logs -t my-app，能确认最后一条日志的时间是否远早于FinishedAt，如果是，说明崩溃发生在日志输出之后 - 对秒退容器，
docker run -it --rm my-image临时交互式运行，比看 logs 更早暴露报错（比如/bin/sh: 1: ./entrypoint.sh: not found）
退出码只是容器生命周期终点的一个快照，它不记录过程。真正难的从来不是“看到 137”，而是确认这个 137 是 OOM Killer 杀的，还是你自己 docker kill -s KILL 干的，又或者是因为挂载卷权限导致进程在 malloc 时段错误——这些都得靠 docker inspect 的 .State.OOMKilled、.HostConfig.Memory 和 docker logs --details 交叉验证。别让 Dashboard 的简洁界面，骗你跳过这一步。
