容器退出码非零说明主进程异常终止，需先通过退出码（如1、127、137、143）快速定位问题类型，再结合docker logs查看具体错误日志，最后按业务场景选择合适重启策略（如unless-stopped或on-failure:3）并配合健康检查实现精准恢复。
容器退出码为非零，说明主进程异常终止，不是正常结束。处理的关键是先定位原因，再选择合适的恢复方式，而不是盲目重启。
看退出码快速判断问题类型
退出码是第一线索，不同数字代表不同失败原因：
- 1：通用错误，比如脚本语法错、命令没找到、应用抛未捕获异常
-
127：命令不存在，常见于启动命令写错（如把
nginx写成ngnix） - 137：被 SIGKILL 杀掉，90% 是内存超限（OOM Killer 触发）
- 143：收到 SIGTERM 后主动退出，通常是被手动 stop 或编排系统优雅终止
查日志确认具体失败点
退出码只告诉“怎么挂的”，日志才说“为什么挂”：
minimax-mcp-docker版（适配极空间）
下载
MiniMax 图片理解 + 网络搜索 MCP 工具。适配 Docker 环境（极空间等），支持图片 OCR 识别、图像内容理解、网络搜索。API Key 安全存储在本地 credentials 文件，不暴露在代码中。
- 用
docker logs --tail 100看最后 100 行输出，重点关注 panic、Connection refused、Permission denied、invalid option 等关键词 - 如果日志为空，可能是进程根本没跑起来——尝试
docker run -it 镜像名 /bin/sh进容器，手动执行启动命令看报错 - 注意：只有输出到 stdout/stderr 的内容才能被
docker logs捕获；写入文件的日志需进容器查（docker exec -it 容器名 ls /var/log）
按场景选重启策略
不是所有非零退出都该无限重启，得匹配业务逻辑：
-
Web 服务、数据库等长期运行服务：用
--restart=unless-stopped，既保障高可用，又允许人工临时停用 -
批处理任务、测试脚本等短时任务：用
--restart=on-failure:3，最多重试 3 次，避免死循环消耗资源 -
调试阶段或已知会失败的任务：先禁用自动重启（
--restart=no），专注查根本原因
配合健康检查提升恢复质量
单靠重启策略不够，容易重启一个“活着但不工作”的容器：
- 在镜像中加
HEALTHCHECK指令，例如HEALTHCHECK --interval=30s --timeout=3s --retries=3 CMD curl -f http://localhost/health || exit 1 - 在 Compose 中配
deploy.restart_policy.condition: on-failure，让编排层只在健康检查失败时才触发替换 - 这样能避免容器进程还在、但服务实际不可用的情况被忽略
