容器启动失败时应先执行 docker ps -a 查看状态，再用 docker logs --tail 20 查末尾日志；常见原因有端口被占、启动命令文件缺失、挂载目录权限不足，需分别排查并处理。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
当你在执行 docker run 或 docker-compose up 后，容器一闪而过就退出，或者根本起不来，连日志都看不到几行，这种“启动失败”对刚接触 Docker 的人来说特别抓瞎——不是代码写错了，也不是镜像没拉下来，就是卡在启动那一秒，连错在哪都不知道。
先看一眼容器到底有没有起来
别急着重试，先确认它是不是真没启动：
运行 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 的用户
