实战：容器反复重启，从退出码与日志定位原因

容器反复重启时，先不要把 restart 策略关掉或不断重建。应把退出原因、健康状态、资源和应用日志放进同一时间窗口分析。

<!-- more -->

## 记录退出原因

先检查 State 中的 ExitCode、Error、OOMKilled 与 FinishedAt，再读取近期日志。退出码 137 可能与 SIGKILL 有关，但不能单凭这一数字认定是内存不足；需要结合 OOMKilled 与内核日志。

## 分清进程退出与健康异常

unhealthy 不必然等于容器退出。Docker 的普通 restart 策略通常围绕进程退出生效，健康检查本身并不自动提供所有恢复行为。先明确编排工具的实际规则，再解释看到的状态。

## 从首次错误开始

数据库连接拒绝、配置解析失败和目录权限错误，可能都导致入口脚本退出。先找到第一次具体错误，后续重试日志通常只是同一问题的重复。容器内的 localhost 指向也要结合网络模式判断。

## 验证修复而不是只看 Up

修复配置后观察服务是否保持运行，并从入口执行实际请求。保留日志与变更记录；如果必须重建，先确认数据挂载、当前镜像和备份，不要用重装覆盖故障证据。

## 操作参考

```text
docker inspect CONTAINER --format '{{json .State}}'
docker logs --since 20m --tail 200 CONTAINER
docker stats --no-stream CONTAINER
```

示例占位符需替换为自己的环境。涉及生产服务时先保留备份，阅读命令用途后再执行。

## 参考资料

- [官方说明](https://docs.docker.com/engine/containers/start-containers-automatically/)
- [专题阅读路线](/topics/)