最快速定位容器启动失败的方法是用 docker logs 查看错误输出，需结合 --tail、-f 等参数及 docker ps -a、docker inspect 等命令综合分析端口冲突、文件路径错误、配置问题或依赖未就绪等常见原因。

直接用 docker logs 查看容器启动失败时的错误输出，是最快速定位问题的方式——但很多人忽略了加参数、查历史、配合其他命令，导致反复重启却看不出原因。

查看最近一次启动的日志（最常用）

容器退出后，日志仍保留在本地。运行以下命令可立即看到最后一次启动时的完整输出：

• docker logs <容器名或ID>：显示全部日志（包括已退出容器）
• docker logs --tail 50 <容器名>：只看最后50行，适合日志很长的情况
• docker logs -f <容器名>：实时跟踪（仅对仍在运行的容器有效）

查不到日志？先确认容器是否真启动过

如果执行 docker logs 提示“No such container”，说明容器根本没成功创建或已自动被清理。此时应：

• 用 docker ps -a 查看所有容器（含已退出的），确认容器是否存在、状态是否为 Exited (1) 类错误码
• 若连记录都没有，可能是 docker run 命令本身出错（如镜像拉取失败、参数语法错误），需检查终端上 run 命令的原始输出
• 某些 Docker 版本在容器秒退时可能来不及写日志，可加 --log-driver=local 启动守护进程来增强日志可靠性（适用于调试环境）

结合日志快速判断常见故障类型

日志里出现这几类关键词，基本能锁定方向：

• “Address already in use” 或 “port is already allocated” → 端口被占，改 host 端口或停掉冲突服务
• “no such file or directory”、“exec format error” → 启动命令路径错、脚本权限不足、或镜像架构不匹配（如在 ARM 机器跑 x86 镜像）
• “failed to load config”、“invalid yaml” → 配置文件挂载错误或格式有误，重点检查 -v 路径和文件内容
• “Connection refused”、“timeout” → 依赖服务（如数据库、Redis）未就绪，需确认依赖容器是否运行、网络是否互通

进阶技巧：一次性查清启动全过程

单靠 logs 有时不够，建议组合使用：

• docker inspect <容器名>：看 State.ExitCode 和 Mounts 是否挂载成功
• docker events --since '2m'：查看两分钟内所有容器事件，确认是否被自动删除或健康检查杀掉
• 对反复崩溃的容器，加 --restart=on-failure:1 启动，并立刻 docker logs，避免日志被覆盖

日志是容器排障的第一现场，不用猜、不用重装，盯住输出里的第一行报错，90% 的启动问题当场就能解决。