Docker Compose 如何处理容器启动失败的错误排查

容器启动失败是配置、环境或应用层问题的明确信号，需结合日志（如docker-compose logs --previous）、状态（如docker-compose ps显示Exit 137）和配置（如docker-compose config验证语法）三者快速定位根因。

容器启动失败不是随机事件，而是配置、环境或应用层问题的明确信号。重点不是反复重试，而是快速定位根本原因——日志、状态和配置三者结合，就能覆盖 90% 以上的常见故障。

看日志：第一时间获取退出线索

容器刚启动就退出，最直接的信息在日志里：

1. 用 docker-compose logs <service_name> 查看最近输出；加 --tail 50 只看末尾关键行
2. 如果容器已退出但没重启，加 --previous 参数读取上一次运行的日志：

   docker-compose logs --previous <service_name>

3. 日志里出现 Permission denied，大概率是挂载卷权限不对；看到 Connection refused 或 timeout，说明依赖服务没起来或网络不通

查状态：确认卡在哪一步

运行 docker-compose ps 看服务当前状态：

1. Exit 1 或 Exit 137：应用崩溃或被系统杀掉（通常是内存超限）
2. Restarting：容器反复启动失败，进入自动重试循环
3. Created 但不变成 Up：可能卡在健康检查、初始化脚本或端口绑定阶段
4. 完全不显示该服务：可能是 docker-compose.yml 语法错误，导致服务未被识别

验配置：从文件本身找硬伤

很多失败源于 YAML 文件的低级错误：

1. 先运行 docker-compose config —— 它会解析并打印出最终生效的配置；如果报错，说明缩进、冒号后空格、引号缺失等语法问题存在
2. 检查 ports 映射：宿主机端口是否被占用？可用 lsof -i :8080（Linux/macOS）或 netstat -ano | findstr :8080（Windows）验证
3. 检查 volumes 路径：本地目录是否存在？路径写的是相对路径还是绝对路径？Windows 用户注意反斜杠和路径分隔符
4. 确认 image 名称拼写正确，私有镜像记得提前 docker login

试运行：绕过编排单独验证

把问题隔离出来，能快速判断是 Compose 问题还是镜像/应用本身问题：

1. 用 docker run 手动启动同一个镜像，带上关键参数（如 -v、-e、--network）：

   docker run -it --rm -p 8080:80 nginx:alpine

2. 如果手动能跑通，说明问题出在 docker-compose.yml 的某项配置（比如 depends_on 写错了、healthcheck 超时太短）
3. 如果手动也失败，那问题在镜像构建逻辑、入口命令或应用代码层面