容器启动失败需先查 docker ps -a 确认存在状态，再用 docker logs --tail 20 查日志；常见原因：端口被占（lsof -i :端口）、启动命令错误（exec user process caused: no such file）、挂载权限不足（chmod 或 --user 指定 UID）。
苹果电脑上Docker容器启动失败时，常表现为终端一闪而过、docker ps 看不到容器、或报错信息极短甚至空白——这不是镜像没拉下来，而是容器在启动命令执行前就已退出，必须用 macOS 特有路径快速定位真实原因。
先确认容器到底有没有“活过”
别急着重跑，先查它是否曾存在：
执行 docker ps -a，重点看 STATUS 列。如果显示 Exited (1)、Created 或 Restarting，说明容器确实启动失败；若列表为空，代表连创建都失败了，问题出在 run 命令参数本身。
这一步跳过，你可能在修一个根本没生成的容器 ID。
查日志：只盯最后 20 行，别翻全量
方法一（最常用）：docker logs --tail 20 容器名或ID
方法二（带时间戳，适合判断启动卡点）：docker logs -t --tail 10 容器名或ID
【关键提醒】如果提示 No such container，说明容器已自动删除——这时必须用 docker ps -a 找出刚退出的完整容器 ID（不是名字），再用 ID 查日志，否则白忙一场。
高频三类原因及 macOS 专属解法
① 端口被占（占 macOS 用户故障率 67%）
容器想绑 8080，但宿主机上的 Control Center、Web Sharing 或某个 Electron 应用正悄悄占用。
→ 在终端运行：lsof -i :8080 | grep LISTEN
→ 若输出中 PID 对应进程不是 Docker 相关（比如是 Google、Zoom 或 node），要么杀掉它：kill -9 PID，要么改端口重跑：docker run -p 8081:8080 ...
② 启动命令崩了（常见于自建镜像）
比如 Dockerfile 写了 CMD ["sh", "entrypoint.sh"]，但镜像里压根没这个文件。
→ 日志里通常出现 exec user process caused: no such file or directory
→ 验证方式：docker run --rm -it 镜像名 ls -l /，确认路径和权限是否真存在
③ 挂载目录权限不足（macOS 文件系统默认不认 Linux UID）
尤其当你用 -v ~/Projects/myapp:/app 挂载本地目录，而容器内用户是 node 或 www-data，就会报 Permission denied 或 mkdir: cannot create directory。
→ 临时解法：chmod -R 755 ~/Projects/myapp
→ 长期解法：在 Dockerfile 开头加 USER 501（macOS 当前用户 UID，可用 id -u 查），或改用 docker run --user $(id -u):$(id -g) 显式指定
