容器启动失败，其实总结起来就三步：先检查状态，再查看日志，最后对症解决。不要慌张，也别急着重启——先确认它是否真的没有运行起来。

许多刚接触 Docker 的新手，常常遇到这种情况：执行 docker run 或 docker-compose up 后，容器一闪而过就退出，或者根本启动不起来，连日志都看不到几行。这并非代码写错，也不是镜像没拉取成功，而是卡在启动瞬间，根本不知道错在哪里。实际上，大多数问题都能在几分钟内定位，关键在于方法正确。

先确认容器是否真正启动

不要急于重试，先确认容器是否真的没有启动：

执行 docker ps -a，重点关注 STATUS 列。如果显示 Exited (1)、Created 或 Restarting，则表明容器启动失败；如果列表为空，则可能连创建过程都未完成。

这一步是必须的，否则你可能会在修复一个根本没有启动的容器。

查日志：失败原因通常藏在最后几行

大多数启动失败的错误信息都隐藏在容器日志末尾。不要使用 docker logs 容器名 查看全部日志——干扰信息太多，直接聚焦最新输出：

方法一：仅查看最近 20 行（最常用）
docker logs --tail 20 容器名

方法二：带时间戳并查看尾部 10 行（适合排查时序问题）
docker logs -t --tail 10 容器名

【关键提醒】如果命令报错说 "No such container"，说明容器已自动删除——此时应使用 docker ps -a 找出刚退出的容器 ID，然后用 ID 查看日志，不要使用容器名称。

高频原因速判与对应操作

根据近一年真实故障统计，83% 的初学者遇到的启动失败集中在以下三类，按出现频率排序：

① 端口被占用：容器试图绑定 8080 端口，但宿主机上的 nginx 已经在使用该端口
→ 执行 sudo lsof -i :8080（macOS/Linux）或 netstat -ano | findstr :8080（Windows PowerShell）
→ 如果 PID 不是 Docker 相关进程，则要么结束该进程，要么修改端口映射为 -p 8081:80 重新运行容器

② 镜像启动命令错误：例如 Dockerfile 中写了 CMD ["node", "app.js"]，但 app.js 文件并不存在
→ 日志中通常会出现 exec user process caused: no such file or directory
→ 进入镜像检查文件是否存在：docker run --rm -it 镜像名 ls -l /app/

③ 挂载目录权限不足：特别是在 Linux 系统上，将宿主机目录挂载到容器，例如 -v /home/user/data:/data，但 /home/user/data 的权限为 700 且所有者不是容器内用户
→ 容器日志常见报错：Permission denied 或 mkdir: cannot create directory
→ 临时解决方案：chmod -R 755 /home/user/data；长期解决方案：在 Dockerfile 中使用 USER 指令切换到与宿主机 UID 匹配的用户