docker容器退出码是主进程（pid 1）终止时返回的posix标准整数值，0表示成功退出，1–125为应用错误，126–127为shell执行失败，128+n对应信号n（如137=sigkill，143=sigterm），需结合docker logs、inspect exitcode及oomkilled字段交叉验证根因。

Docker 容器退出码不是随机数字，而是操作系统进程退出机制在容器场景下的直接体现。它本质上是主进程（PID 1）终止时返回的整数值，Docker 将其原样记录在容器状态中。剖析它的关键，在于理解退出码来源、信号映射、常见模式及对应根因。

退出码本质：进程级反馈，非 Docker 特有
容器生命周期完全绑定于其前台主进程。该进程结束时调用 exit() 或被系统信号终止，内核生成退出码并传递给 Docker daemon。因此，退出码分类严格遵循 POSIX 规范：

• 0：显式成功退出，代表任务完成（如 docker run ubuntu echo hello）
• 1–125：应用层错误，由程序自身 exit(1)、未捕获异常、脚本语法错误等触发
• 126–127：Shell 层执行失败，如命令无权限（126）、路径不存在或命令未找到（127）
• 128+N：表示进程被信号 N 终止（例如 128+9=137 → SIGKILL；128+15=143 → SIGTERM）

高频退出码与典型根因对照
这些数字背后往往指向明确的技术问题，可快速缩小排查范围：

• Exit Code 0

  • 主进程正常结束，如批处理任务完成、健康检查脚本跑完
  • 注意：不等于“服务持续运行”，而是“执行完毕后退出”

• Exit Code 1

  • Python/Node.js 程序抛出未处理异常
  • Shell 脚本语法错误或 set -e 下某命令失败
  • 配置文件缺失、环境变量未设置导致初始化失败

• Exit Code 126

  • 启动脚本缺少执行权限（chmod +x 忘记）
  • 使用了不兼容架构的二进制（如 x86_64 镜像在 ARM 主机运行）

• Exit Code 127

  

  Docker Cli

  使用 Docker CLI 构建、运行、停止、检查和管理容器与镜像的助手。用于执行容器相关任务。

  下载
  • ENTRYPOINT 或 CMD 指向的路径根本不存在（拼写错误、路径层级错）
  • 基础镜像里没装所需工具（如脚本里用了 jq，但 Alpine 镜像未 apk add jq）

• Exit Code 137

  • 内存超限触发 OOM Killer（最常见），可通过 dmesg | grep -i "killed process" 确认
  • 容器设置了 --memory 限制，但应用实际内存需求超出

• Exit Code 139

  • C/C++ 程序访问非法内存地址（空指针解引用、数组越界）
  • 动态链接库版本冲突或 CPU 指令集不兼容（如 AVX 指令在旧 CPU 上运行）

• Exit Code 143

  • 手动执行 docker stop 或 Kubernetes 发送 SIGTERM
  • 若非预期退出，需检查是否健康检查失败触发重启策略、或 stop_timeout 设置过短

诊断流程要闭环，不能只看数字
单看退出码容易误判。必须结合三要素交叉验证：

• docker logs <container_id></container_id>：看 stdout/stderr 是否有报错、堆栈或连接拒绝信息
• docker inspect <container_id> --format='{{.State.ExitCode}}'</container_id>：确认真实退出码（排除 docker ps 显示延迟）
• docker inspect <container_id> --format='{{.State.OOMKilled}}'</container_id>：对 137 码，此项为 true 才是 OOM 实锤

不复杂但容易忽略