最准方式是用 docker inspect 查退出码，它绕过日志缺失或秒退干扰，直接获取系统记录的真实 ExitCode；ExitCode 为 0 表示正常退出，非零则对应具体故障：1 是应用内部错误，127 是命令找不到，137 是 OOM 被杀，128+N 表示收到信号终止。
直接用 docker inspect 查退出码是最准的方式，它能绕过日志缺失或秒退干扰，拿到容器终止时系统记录的真实状态。
提取 ExitCode 字段定位根本原因
退出码不是随便生成的，它直接对应 Linux 进程终止行为。执行以下命令获取精确退出码：
-
docker inspect -f '{{.State.ExitCode}}' <容器名或ID>—— 只输出数字，比如 1、127、137 -
docker inspect <容器名或ID> | grep -A 5 "State"—— 看完整 State 段，确认 ExitCode、FinishedAt 和 Error 字段是否为空
注意：ExitCode 为 0 表示正常退出（比如你手动 docker stop），非零才代表异常。如果 Error 字段有内容（如 "oci runtime error: exec failed"），基本就是启动命令层面的问题。
结合 ExitCode 快速判断常见故障类型
不同退出码指向不同层级的问题，不用猜，直接对照：
-
1：应用内部错误，比如配置文件路径错、依赖库没装、脚本语法错误——重点看
docker logs输出 -
127：命令找不到，常见于
ENTRYPOINT或cmd写错路径，或镜像里缺少可执行文件（如写成node app.js但没装 Node） -
137：被系统 OOM Killer 杀掉，说明内存超限——检查
docker stats历史峰值，或docker inspect中HostConfig.Memory是否设得太小 - 128 + N（如 137 = 128 + 9）：表示收到信号终止，137 就是 SIGKILL（信号 9），143 是 SIGTERM（信号 15）
看 RestartCount 和 FinishedAt 辅助判断问题性质
如果容器在反复重启，inspect 里的这两个字段比 ExitCode 更能说明问题持续性：
-
RestartCount 大于 0：说明设置了
restart: always或类似策略，问题不是单次失败，而是每次启动都失败 - FinishedAt 时间非常接近 StartedAt（差几秒内）：典型“启动即退”，大概率是入口命令根本没跑起来，而不是程序跑一会儿再崩
-
Status 显示
exited但 OOMKilled 为true：不用再查日志，直接调高内存限制
对比 HostConfig 确认运行参数是否合理
有些退出看似随机，其实是运行时配置冲突导致的。用下面命令检查关键设置：
-
docker inspect -f '{{.HostConfig.Memory}}' <容器名>—— 看是否设了内存限制且太低 -
docker inspect -f '{{.HostConfig.Binds}}' <容器名>—— 检查挂载卷路径是否存在、权限是否允许容器读写 -
docker inspect -f '{{.Config.Cmd}}' <容器名>—— 确认实际执行的命令和你预期一致，尤其注意 shell 与 exec 格式差异
比如挂载了一个宿主机目录到容器 /config，但宿主机该路径是空的或属主不是 root，某些程序启动时检测不到配置就会直接退出，ExitCode 往往是 1。
