容器一启动就退出，关键先看状态、日志、资源：Exited (0)为正常结束，非0退出码（如1、127、137）指向命令错误、文件缺失或OOM；docker logs查stdout/stderr线索；137需检查内存限制及tmpfs配置；最后用docker run -it交互验证启动命令。
看退出码和状态，分清“正常结束”还是“挂了”
执行 docker ps -a，找到目标容器，重点盯 STATUS 列：
-
Exited (0)：主进程跑完就收工，比如
docker run hello-world，这是设计如此，不用修； - Exited (1)、(127)、(137)：异常退出——1 多是命令写错或依赖缺失，127 常见于找不到可执行文件，137 几乎等于被系统杀掉（OOM）；
- Up 2 seconds 或反复重启：说明 pid 1 进程没稳住，大概率是应用后台化（如 nginx 默认 daemon on）、脚本执行完就退出，或 entrypoint 写法不对。
查日志，90% 的线索藏在 stdout/stderr 里
用 docker logs --tail 100 容器名 看最后百行输出。注意：
minimax-mcp-docker版（适配极空间）
下载
MiniMax 图片理解 + 网络搜索 MCP 工具。适配 Docker 环境（极空间等），支持图片 OCR 识别、图像内容理解、网络搜索。API Key 安全存储在本地 credentials 文件，不暴露在代码中。
- 只能看到打印到控制台的日志，写进
/var/log/xxx.log的内容不会出现； - 如果日志空空如也，别急着怀疑代码，先检查是不是应用根本没启动成功（比如配置文件路径错、环境变量没传）；
- 常见报错如
Connection refused（连不上数据库）、No such file or directory（找不到 jar 或 bin）、Address already in use（端口被占），直接定位根因。
查资源限制，OOM 和 tmpfs 不够最隐蔽
退出码是 137 或 docker inspect 容器名 显示 "OOMKilled": true，基本就是内存超限：
- 运行
dmesg | grep -i "killed process"，确认内核是否杀了它； - 检查容器是否设了
-m或mem_limit，数值是否太小； - 临时目录（如
/tmp）如果挂了 tmpfs 却没设 size，应用写缓存失败也会静默退出——加--tmpfs /tmp:size=512m就能试出来。
进容器手动验证，绕过启动逻辑直击问题
如果以上都看不出头绪，用 docker run -it 镜像名 /bin/sh 进去，手动执行启动命令（比如 nginx -t、java -jar app.jar）：
- 能跑通说明配置没问题，问题出在 Docker 启动方式（CMD/ENTRYPOINT 写法）；
- 报错则暴露真实依赖或权限问题（比如证书路径不对、用户没权限读配置）；
- 特别注意：有些镜像要求非 root 用户运行，但 Docker 默认以 root 启动，得加
--user参数模拟。
