Restarting 状态表明容器进程启动后立即退出，需禁用 restart 策略、用 docker inspect 查 ExitCode、docker logs 查错误；ExitCode 127 表示命令未找到，137 表示 OOM Kill。
别急着删容器或重启 Docker Desktop，Restarting 状态本身就在告诉你：进程启动了、又秒退了、Docker 正在循环拉起它——关键不是“怎么让它跑起来”，而是“它刚起来就死，到底说了什么”。
怎么看 Restarting (1) 里的数字和时间
Restarting (1) Less than a second ago 这串文字里，括号里的 1 不是重启次数，是容器主进程（PID 1）退出时返回的 exit code；Less than a second ago 表示每次存活时间极短，基本没机会初始化或刷日志到磁盘。这意味着问题卡在启动最前端，比如配置加载失败、依赖未就绪、命令根本执行不了。
常见误操作是直接 docker-compose down && up，结果新容器覆盖旧状态，原始错误线索全丢。先用 docker ps -a 找到那个反复出现的容器 ID，后续所有操作都盯住它。
为什么 docker logs 经常是空的
因为进程存活时间太短，stdout/stderr 还没 flush 到日志缓冲区就退出了；或者应用自己没开日志输出（比如某些 Go 二进制默认不打 stdout）。不能因为看不到日志就认为“没报错”。
实操建议：
- 立刻执行
docker logs --tail=100 --timestamps，加--timestamps看是否有零星几行带毫秒级时间戳的输出 - 如果仍为空，改用
docker inspect查State.ExitCode和State.FinishedAt，确认是否稳定返回1、127或137 -
ExitCode为127表示CMD或ENTRYPOINT指定的命令根本找不到（路径错、镜像里没装）、137基本等于内存被 OOM Kill
临时禁用 restart 策略才能看到 Exited 状态
Docker Desktop 默认可能启用了 restart: always，这会让容器一退出就立刻重拉，你永远卡在 Restarting 状态，没法做任何交互式排查。
必须先打断这个循环：
- 如果是
docker-compose.yml启动的，注释掉对应服务下的restart:行，再执行docker-compose down && docker-compose up - 如果是
docker run启动的，记下原命令，去掉--restart=always参数重新运行 - 容器变成
Exited (1)后，立刻执行docker logs——这次大概率能看到真实错误，比如ERROR: failed to connect to redis: connection refused或/bin/sh: can't open '/app/start.sh': No such file - 必要时用
docker exec -it（前提是镜像带 shell）进去手动跑启动命令，看报什么错/bin/sh
检查依赖服务和资源限制这两处最容易被跳过
很多人查完日志没报错就放弃，其实问题常藏在外部：MySQL 容器还没起来，你的应用就去连，连不上直接 exit 1；或者 Docker Desktop 资源配得太低（默认仅 2GB 内存），应用一启动就触发 OOM Kill，退出码变成 137。
验证方法：
- 用
docker-compose ps确认所有依赖服务状态是否为Up，尤其注意端口映射和网络是否同属一个自定义 network - 打开 Docker Desktop 设置 → Resources → Memory，调高到至少 4GB（Java/Node 应用建议 6GB+），改完要重启 Docker Desktop 生效
- 检查磁盘空间：
df -h看/var/lib/docker所在分区是否满（特别是 WSL2 下的\wsl$分区） - 对 MySQL、PostgreSQL 类容器，额外检查
docker logs是否有mysqld: Can't create/write to file——这是数据目录权限问题，不是应用代码问题
真正卡点在于：退出码 1 太泛，它可能是配置错、路径错、连不上 DB、权限不够、甚至只是脚本里少了个 exec 导致 PID 1 不是你的程序。必须用禁用 restart + inspect + logs 三步锁死第一次退出现场，否则所有猜测都是白费。
