🔒
OpsAI 隐私承诺
· 本工具所有计算均在您的浏览器本地完成，文件与数据绝不会上传至任何云端服务器，断网亦可使用Docker Compose 排错速查
按症状 → 线索 → 修复的链路组织。先跑这条万能的看日志命令，再对照下面找你的场景：
docker compose logs --tail 50 服务名
你的症状是哪一个？
🩹 通用急救包（80% 的问题先看这四个）
看完整日志
docker compose logs -f --tail 100
看容器状态和退出码
docker compose ps -a && docker inspect <容器名> --format "{{.State.ExitCode}} {{.State.Error}}" 全部重来（缓存是万恶之源）
docker compose down && docker compose build --no-cache && docker compose up -d
验证 compose 文件语法
docker compose config
什么时候用得上
- 本机 docker compose up 起不来，日志只有一行 exit 1，不知道从哪查起
- 线上容器每 30 秒重启一次，要根据退出码判断是应用报错还是被 OOM 杀掉
- 换服务器后容器之间连不上，不确定该写 localhost 还是 compose 里的服务名
常见问题
exit code 137 一定是内存不够吗？
不一定。137 等于 128 加 9，表示进程收到 SIGKILL 信号，多数由内存不足触发，也可能是有人手动执行 docker kill。用 inspect 看 OOMKilled 是不是 true，才算实锤，别一看到 137 就加内存。
depends_on 能保证数据库先起来吗？
只能保证启动顺序，不保证数据库已经能接连接。要等就加 healthcheck，再写 condition: service_healthy，否则应用比数据库先就绪，照样启动即退出。
镜像一直 i/o timeout，换加速器就行吗？
多数情况是。改 /etc/docker/daemon.json 里的 registry-mirrors 后要 restart docker；拉官方镜像还得在镜像名前面补 library 前缀，少这一层照样超时，很多人卡在这里。
觉得好用？请老架构师喝杯咖啡 ☕ 加微信 qcwindwin 聊业务也可以