容器频繁重启本质是主进程反复退出，需依退出码（如137=OOM、1=启动失败、127=命令未找到、255=脚本错误）定位原因，结合日志、dmesg、资源监控及临时禁用重启策略深入排查。
容器频繁重启形成死循环，本质是主进程反复退出，又被 docker 按重启策略拉起。关键不是“怎么让它不重启”，而是“它为什么一启动就退”。排查要从退出原因入手，层层下钻。
看退出码，快速锁定大方向
运行 docker ps -a，找到 STATUS 列里带括号数字的容器，比如 Restarting (137) 2 seconds ago。括号里的数字就是退出码，它是第一线索：
- 137：几乎肯定是内存被系统 OOM Killer 杀掉，不是应用自己崩的
- 1：应用启动失败，比如配置错、连不上数据库、端口占用了
- 127：CMD 或 Entrypoint 命令根本找不到，路径写错或镜像里没装这个程序
- 255：入口脚本执行出错，比如 shell 脚本里某条命令失败但没加 set -e
查日志，抓取崩溃瞬间的线索
退出码只是标签，日志才是证据。重点不是看“有没有报错”，而是看“最后几行在干什么”：
- 用 docker logs --tail 100 <容器ID> 看最近输出，找 ERROR、FATAL、panic、connection refused、No such file 这类关键词
- 如果容器重启太快，日志一闪而过，就用 docker logs -f <容器ID> 实时盯住，等它下次启动时直接看到全过程
- 对 docker-compose，用 docker-compose logs -f service_name，更直观
查资源，确认是不是被系统“动手”了
退出码是 137 时，别急着改代码，先看宿主机是不是真没内存了：
- 运行 dmesg -T | grep -i "killed process"，如果输出里有你的容器名和 “Out of memory”，就是铁证
- 运行 free -h 和 docker stats <容器ID>，对比容器内存 limit 和实际 usage，看是否长期打满
- 检查 docker inspect <容器ID> 输出里 "OOMKilled": true 或 "ExitCode": 137 是否同时存在
临时禁用重启，让错误“停下来”
一直 restarting，等于错误状态被掩盖。最有效的调试动作是让它退出后就停住：
- 编辑 docker-compose.yml，把对应服务的 restart: always 或 restart: unless-stopped 整行删掉或注释掉
- 执行 docker-compose down && docker-compose up 重建
- 这时容器启动失败后会变成 Exited (1) 状态，你可以放心用 docker logs 或 docker exec -it <容器ID> /bin/sh 进去查文件、试命令
