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
-
ENTRYPOINT或CMD指向的路径根本不存在（拼写错误、路径层级错） - 基础镜像里没装所需工具（如脚本里用了
jq，但 Alpine 镜像未apk add jq）
-
-
Exit Code 137
- 内存超限触发 OOM Killer（最常见），可通过
dmesg | grep -i "killed process"确认 - 容器设置了
--memory限制，但应用实际内存需求超出
- 内存超限触发 OOM Killer（最常见），可通过
-
Exit Code 139
- C/C++ 程序访问非法内存地址（空指针解引用、数组越界）
- 动态链接库版本冲突或 CPU 指令集不兼容（如 AVX 指令在旧 CPU 上运行）
-
Exit Code 143
- 手动执行
docker stop或 Kubernetes 发送SIGTERM - 若非预期退出，需检查是否健康检查失败触发重启策略、或
stop_timeout设置过短
- 手动执行
诊断流程要闭环，不能只看数字
单看退出码容易误判。必须结合三要素交叉验证：
-
docker logs <container_id>：看 stdout/stderr 是否有报错、堆栈或连接拒绝信息 -
docker inspect <container_id> --format='{{.State.ExitCode}}'：确认真实退出码（排除docker ps显示延迟） -
docker inspect <container_id> --format='{{.State.OOMKilled}}'：对 137 码，此项为true才是 OOM 实锤
不复杂但容易忽略
