Docker 容器退出码是进程原生返回值，Docker 仅透传不映射；企业运维需通过统一语义规范、结构化采集富化、编排层主动标注三方面协同实现精准健康判断。
容器退出码本身是操作系统进程的原生返回值，docker 不提供“退出码映射逻辑”这一层抽象——它不转换、不重写、不映射退出码。退出码由 pid 1 进程真实返回，docker 只做透传和记录。企业级自动化运维大屏要准确展示服务健康状态，关键不是“映射退出码”，而是统一解释规则 + 标准化采集 + 上游增强语义。
以下三点构成可落地的支撑链路：
明确退出码语义并固化到交付规范中
每个服务镜像应在 README 或 CI/CD 文档中明确定义常见退出码含义，例如：
-
0：服务正常终止（如计划维护、滚动更新） -
1：配置错误或启动失败（如 env 缺失、端口被占） -
137：OOM 被杀（需关联内存 limit 和实际 usage 判断是否配置不足） -
143：收到 SIGTERM 后优雅退出（属预期行为，不应标红告警） -
255：自定义业务异常（如健康检查连续失败 5 次后主动退出）
该规范需强制纳入镜像构建流水线，在 Dockerfile 中通过 LABEL 注明：
LABEL org.opencontainers.image.description="Exit codes: 0=graceful, 1=config-fail, 137=oom, 143=stop"
统一采集与富化退出信息
大屏不直接读 docker ps -a 的原始 ExitCode，而应通过标准化采集器（如 Prometheus + cAdvisor + 自定义 exporter）获取结构化数据，并补充上下文：
- 容器名、服务名、部署环境（prod/staging）
-
FinishedAt时间戳与运行时长 -
OOMKilled布尔值（来自docker inspectState.OOMKilled） - 实际内存/CPU 使用峰值（来自
docker stats --no-stream或 cAdvisor） - 最近 10 行日志摘要（避免空日志误导，用
docker logs --tail 10防静默失败）
这样一条记录就从 Exited (1) 升级为：
{
"service": "payment-api",
"exit_code": 1,
"oom_killed": false,
"runtime": "2.3s",
"log_snippet": "ERROR config: DB_URL is empty",
"severity": "critical"
}在编排层注入可识别的终止原因标签
单纯依赖退出码易歧义（比如 1 可能是脚本语法错，也可能是业务拒绝启动）。推荐在启动容器时，用环境变量或 label 主动声明意图：
docker run -d \ --label "exit.reason=health-check-failed" \ --env "EXIT_REASON=dependency-unavailable" \ myapp:prod
再配合健康检查失败时的 --restart=on-failure:3，运维大屏即可将 ExitCode=1 + label.exit.reason=health-check-failed 组合判定为“依赖服务不可用”，而非泛化“启动失败”。
不复杂但容易忽略
