容器启动失败主因是端口冲突、日志需带问题精读、权限与挂载路径不匹配、Docker守护进程异常或磁盘空间不足，须按序排查而非盲目重试。
容器启动失败不是随机事件，而是系统在明确告诉你：配置、资源或环境出了问题。关键不是重试，而是读懂错误信号。
端口被占是头号原因
报错里带 port is already allocated 或 Bind for 0.0.0.0:xxx failed，基本可以锁定端口冲突。
- 先查谁在用：Linux/macOS 上运行
sudo lsof -i :8080（把 8080 换成你映射的端口）；Windows 用Get-NetTCPConnection -LocalPort 8080 - 如果是旧容器没删干净，执行
docker ps -a | grep Exited找出残留容器，再docker rm -f <id> - 如果是宿主机其他程序（比如本地起的 Node 服务），要么关掉它，要么改
docker-compose.yml里的端口映射，例如从"8080:80"改成"8081:80"
日志不是翻着看，是要带着问题读
docker logs <container> 只是起点。真正有用的命令组合是：
minimax-mcp-docker版（适配极空间）
下载
MiniMax 图片理解 + 网络搜索 MCP 工具。适配 Docker 环境（极空间等），支持图片 OCR 识别、图像内容理解、网络搜索。API Key 安全存储在本地 credentials 文件，不暴露在代码中。
-
docker logs --tail 100 -t <container>：看最近 100 行，带时间戳，方便比对操作时间 -
docker logs -f <container>：容器一启动就实时盯住输出，很多错误只在启动瞬间闪现 - 如果容器根本起不来（比如刚 run 就 exit），加
--rm参数再试一次：docker run --rm -it your-image，这样能直接看到 stdout/stderr
权限和挂载路径容易被忽略
报错含 permission denied、operation not permitted 或容器内程序提示“无法写入配置目录”，大概率是卷挂载权限问题。
- 检查宿主机目录权限：
ls -ld /path/on/host，确保 Docker 守护进程（通常是 root）有读写权 - Linux 上常见情况：挂载了普通用户目录，但容器以非 root 用户运行 → 在
docker run加--user $(id -u):$(id -g)，或在 Dockerfile 里用USER指令匹配宿主 UID - macOS/Windows 使用 Docker Desktop 时，共享目录需在设置里手动勾选，否则挂载会静默失败
别跳过基础服务状态检查
有时候容器起不来，根源不在容器本身，而在 Docker 守护进程没跑稳。
- 先确认 Docker 服务活着：
systemctl status docker（Linux）或看 Docker Desktop 图标是否显示 “Running” - 如果服务异常，看它的日志：
sudo journalctl -u docker.service -n 50 --no-pager，重点找 failed to start、invalid config、no space left 这类关键词 - 磁盘空间不足很隐蔽：
df -h /var/lib/docker和docker system df一起看，90%+ 使用率就该清理了
