直接用 docker inspect 提取退出码是定位容器异常根源最可靠的第一步，通过 ExitCode 判断是否异常（非零即异常），结合 OOMKilled、FinishedAt、Status 等字段及日志、启动命令、资源限制综合分析故障类型。

直接用 docker inspect 提取退出码，是定位容器异常根源最可靠的第一步。它不依赖日志输出是否完整，也不受进程闪退影响，能准确告诉你“容器为什么停”。

查 ExitCode：确认是否真异常

执行以下命令获取容器退出状态码：

docker inspect --format='{{.State.ExitCode}}'

关键看返回值是否为非零数字。0 表示正常退出；其他数值都代表某种异常。若返回空或报错，说明容器还在运行中，未发生退出事件。

补充验证是否被 OOM 杀掉：

docker inspect --format='{{.State.OOMKilled}}'

返回 true 即确认是内存超限触发的强制终止，和 ExitCode 137 相互印证。

结合 State 字段判断退出性质

运行以下命令查看完整状态快照：

docker-container-rerun-all

顺序检查并可选更新所有已在长期记忆中记录了固定重建命令的 docker run 容器。使用场景：用户...

下载

docker inspect --format='{{json .State}}'

重点关注这几个字段：

• FinishedAt：退出时间，配合日志时间戳交叉比对
• Status：当前是 exited 还是 restarting，区分单次失败还是持续震荡
• Restarting：布尔值，true 表示 Docker 正在按 restart policy 自动拉起
• Dead：若为 true，说明容器已无法响应 runtime 指令，需手动清理

按退出码归类常见故障类型

ExitCode 不是随机数，每个数字背后对应明确的系统行为或应用缺陷：

• 1：主进程崩溃，常见于未捕获异常、语法错误、配置加载失败
• 127：CMD/ENTRYPOINT 命令找不到，镜像缺失二进制或路径写错
• 137：被 SIGKILL 终止，99% 是 OOM —— 检查 OOMKilled 字段+宿主机内存压力
• 143：收到 SIGTERM 后主动退出，多见于手动 stop、滚动更新或健康检查失败触发重启
• 139：发生段错误（SIGSEGV），常因 C/C++ 扩展、JVM 崩溃或底层库不兼容

联动日志与启动参数交叉验证

仅看 ExitCode 容易误判。必须同步检查：

• 日志输出：docker logs ，确认是否有 panic、connection refused、permission denied 等线索
• 启动命令：docker inspect --format='{{.Config.Cmd}}'，核对是否以后台模式运行（如加了 &）
• 资源限制：docker inspect --format='{{.HostConfig.Memory}}'，对比实际内存使用峰值

比如 ExitCode=137 + OOMKilled=true + 日志末尾无报错 → 锁定为资源配置不足；而 ExitCode=1 + 日志含 Error: ENOENT: no such file → 明确是路径或文件缺失。