容器频繁重启主因是退出码137（OOMKilled），表明被内核OOM Killer强制终止；需结合dmesg日志、free -h和df -h排查真实内存与磁盘瓶颈，禁用自动重启策略以暴露根因。
容器频繁重启本身就会加剧资源消耗，尤其当它反复拉起又崩溃时，会持续占用 cpu、内存和磁盘 i/o。真正耗尽服务器资源的，往往不是单次重启，而是背后未被发现的“根因循环”——比如内存泄漏导致 oom 被杀，再重启，再泄漏，再被杀。
看退出码，锁定最可疑的终止原因
退出码是第一线索，直接反映容器为何停下：
- 137：几乎可以确定是被内核 OOM Killer 杀掉的（SIGKILL），不是应用自己退出。此时重点查内存是否真的超限，而不是只看容器 limit 设置
- 143：收到 SIGTERM 后没及时退出，常见于健康检查失败或应用未正确处理信号，可能伴随 CPU 占用高、响应慢
- 1 或其他非零值：应用启动阶段就报错退出，比如配置缺失、依赖服务连不上、权限拒绝等，这类问题通常日志里有明确提示
执行：docker inspect 容器名 | grep -A 5 "State"，重点关注 ExitCode 和 OOMKilled 字段。
查内核日志，确认是否真被 OOM 杀死
即使 OOMKilled: false，也不能排除 OOM。Docker inspect 的这个字段有时不准确，必须看真实内核记录：
- 运行 dmesg -T | grep -i "killed process"
- 若输出中出现类似
Killed process 12345 (your-container-name)，并带Out of memory，就是铁证 - 同时注意后面跟着的
anon-rss值（实际物理内存占用），它比容器 limit 更真实反映应用内存水位
盯住宿主机整体资源，别只看容器自身
容器频繁重启常是结果，不是原因。资源耗尽往往是系统级瓶颈触发的连锁反应：
- 用 free -h 看内存：关注 available 列，不是 free；如果 available 长期低于 500MB，说明系统已吃紧
- 用 df -h 看磁盘：/var/lib/docker 所在分区满会导致容器无法写日志、无法创建新层，间接引发异常退出
- 用 docker stats --no-stream 看所有容器实时资源：找出长期高 CPU（>80%）或内存持续上涨的“嫌疑容器”
临时禁用重启策略，让错误“停下来”
restart: always 或 unless-stopped 会让容器一退出就立刻重试，掩盖原始错误。停掉它，才能看清第一次失败时发生了什么：
- 如果是 docker-compose 启动，注释掉服务下的 restart 行，然后 docker-compose down && docker-compose up
- 如果是 docker run 启动，删掉 --restart 参数，重新运行
- 此时容器失败后会卡在
Exited (X)状态，你就可以放心查日志、进容器调试、甚至用 strace 追踪系统调用
