容器启动失败是配置、环境或应用层问题的明确信号，需结合日志（如docker-compose logs --previous）、状态（如docker-compose ps显示exit 137）和配置（如docker-compose config验证语法）三者快速定位根因。
容器启动失败不是随机事件，而是配置、环境或应用层问题的明确信号。重点不是反复重试，而是快速定位根本原因——日志、状态和配置三者结合，就能覆盖 90% 以上的常见故障。
看日志：第一时间获取退出线索
容器刚启动就退出，最直接的信息在日志里：
- 用 docker-compose logs
查看最近输出；加 --tail 50 只看末尾关键行 - 如果容器已退出但没重启，加 --previous 参数读取上一次运行的日志：
docker-compose logs --previous - 日志里出现 Permission denied，大概率是挂载卷权限不对；看到 Connection refused 或 timeout，说明依赖服务没起来或网络不通
查状态：确认卡在哪一步
运行 docker-compose ps 看服务当前状态：
- Exit 1 或 Exit 137：应用崩溃或被系统杀掉（通常是内存超限）
- Restarting：容器反复启动失败，进入自动重试循环
- Created 但不变成 Up：可能卡在健康检查、初始化脚本或端口绑定阶段
- 完全不显示该服务：可能是 docker-compose.yml 语法错误，导致服务未被识别
验配置：从文件本身找硬伤
很多失败源于 YAML 文件的低级错误：
- 先运行 docker-compose config —— 它会解析并打印出最终生效的配置；如果报错，说明缩进、冒号后空格、引号缺失等语法问题存在
- 检查 ports 映射：宿主机端口是否被占用？可用 lsof -i :8080（Linux/macOS）或 netstat -ano | findstr :8080（Windows）验证
- 检查 volumes 路径：本地目录是否存在？路径写的是相对路径还是绝对路径？Windows 用户注意反斜杠和路径分隔符
- 确认 image 名称拼写正确，私有镜像记得提前 docker login
试运行：绕过编排单独验证
把问题隔离出来，能快速判断是 Compose 问题还是镜像/应用本身问题：
- 用 docker run 手动启动同一个镜像，带上关键参数（如 -v、-e、--network）：
docker run -it --rm -p 8080:80 nginx:alpine - 如果手动能跑通，说明问题出在 docker-compose.yml 的某项配置（比如 depends_on 写错了、healthcheck 超时太短）
- 如果手动也失败，那问题在镜像构建逻辑、入口命令或应用代码层面
