容器启动失败本质是主进程未持续运行，需通过退出码、日志、配置三者交叉验证：先用docker ps -a查STATUS和退出码，再用docker logs定位错误，最后用docker inspect确认CMD、Env等配置是否合法且匹配运行时环境。
容器启动命令执行失败，本质是容器内主进程没能按预期运行起来。关键不是看“启动了没”，而是看“为什么没持续运行”。排查要从退出码、日志、配置三者交叉验证入手。
先确认真实退出状态和原因
运行 docker ps -a 找到目标容器，注意 STATUS 列是否显示 Exited (X)。括号里的数字 X 就是退出码，它是第一线索：
- ExitCode 1：应用自身报错，比如配置文件路径错误、数据库连接失败、代码 panic
-
ExitCode 125：Docker 命令层面失败，常见于
docker run参数写错（如非法端口、不存在的卷路径） - ExitCode 137：被系统 OOM Killer 杀掉，说明内存严重不足
- ExitCode 139：段错误，多见于二进制不兼容或镜像损坏
用这条命令一次性看清状态全貌：
docker inspect --format='{{.State.Status}} {{.State.ExitCode}} {{.State.OOMKilled}} {{.Config.Cmd}}' [容器ID]
立刻查日志，但得会看关键行
docker logs [容器ID] 是最直接证据源，但别只扫一眼就放弃。重点盯这些位置：
- 最后一行或倒数几行：很多程序崩溃前只来得及输出一句 error 或 panic
- 含 failed to、permission denied、no such file、connection refused 的行
- 启动日志里有没有 “Starting…” 后突然中断？那大概率是进程启动后立刻退出，说明 CMD 没守住前台
高效查看技巧：
• --tail 50 看最近 50 行
• --since "1m" 查 1 分钟内的输出
• 2>&1 | grep -i error 过滤错误关键词
检查启动命令本身是否合法
容器必须靠一个前台进程维持运行。如果 CMD 执行完就退出（比如写了 npm start & 或 python app.py &），容器立刻结束。
- 用 docker inspect [容器ID] | jq '.Config.Cmd' 确认实际执行的命令
- 进镜像手动试：运行 docker run -it --rm [镜像名] sh，然后手动执行 CMD 中的命令，观察是否卡住、报错或后台化
- 常见修复：Node.js 改用
node server.js；Python 改用exec python app.py（加 exec 保证 PID 1）
验证环境与依赖是否就绪
命令能执行，不代表它能跑通。常因缺失依赖或权限卡住：
-
环境变量缺失：日志出现 ENV_VAR is not set 或 undefined variable，用
docker inspect检查.Config.Env字段 - 挂载路径问题：-v 映射的宿主机目录不存在，或容器内用户无读写权限（尤其 Alpine 镜像默认非 root）
-
配置文件不可达：CMD 中引用的
/config.yml实际没挂载进去，或路径拼错 - 临时验证法：用
docker run -it --rm -v $(pwd)/conf:/app/conf [镜像名] ls -l /app/conf看文件是否真在
