应结合 CLI 命令排查 Docker Compose 服务真实状态：docker compose ps 查服务级状态与健康检查，docker compose top 查进程级资源，docker compose config 验证生效配置及路径，WSL2 环境需在终端内执行并避免 /mnt/ 路径。
直接在 Docker Desktop GUI 里点开「Containers / Apps」标签页，就能看到所有 docker-compose.yml 启动的服务状态——但这个视图不显示服务依赖、健康检查失败原因或配置来源路径，容易误判“运行中”就是“可用”。真正要查清状态，得结合 CLI 和项目上下文。
docker compose ps 显示服务实际运行状态
GUI 的「Running」只是容器进程存在，docker compose ps 才反映 Compose 层面的服务状态（比如是否完成初始化、是否被 depends_on 卡住）。
- 必须先进入
docker-compose.yml所在目录再执行，否则报错No such file or directory: docker-compose.yml - 输出中
Status列为Up About X minutes不代表健康，要看Health列（如显示unhealthy或空白，说明健康检查没通过或没定义） - 如果某服务状态是
Restarting (1)，大概率是启动失败后被自动重启，这时要立刻看日志：docker compose logs -f <service_name></service_name>
docker compose top 查进程级资源占用
GUI 的 CPU/Mem 是整个容器的汇总值，docker compose top 能看到服务内具体哪个进程在吃资源，尤其适合排查 Python/Node.js 类服务的内存泄漏。
- 默认只显示主进程（如
python app.py），加-H参数才显示完整进程树 - 输出字段顺序固定：
PID USER TIME COMMAND，注意TIME是 CPU 时间，不是运行时长 - 如果某服务
top输出为空，说明容器进程已退出，但 Compose 还没清理状态——此时ps仍显示Up，属于典型假运行
docker compose config 验证配置与生效路径
状态异常时，90% 的原因是本地改了 docker-compose.yml 但没重新部署，或者用了 --file 指定非默认文件却忘了在其他命令里同步。
-
docker compose config会解析并打印最终生效的配置（含环境变量展开、extends 合并结果），是判断“当前运行的到底是不是你改的那份”的唯一可靠方式 - 加
--resolve-image-digests可强制解析镜像 SHA256，避免因镜像 tag 被覆盖导致服务行为突变 - 如果提示
services.xxx.ports is invalid，常见于 Windows 上用反斜杠写路径：./conf\nginx.conf→ 必须改成正斜杠./conf/nginx.conf
Windows 下 WSL2 环境的特殊陷阱
Docker Desktop for Windows 底层跑在 WSL2，但 docker compose 命令在 PowerShell/CMD 中执行时，工作目录路径会被自动转换，导致找不到 docker-compose.yml 或挂载卷路径错误。
- 用
wsl -l -v确认 WSL2 发行版状态，如果显示Stopped，GUI 里服务可能“看起来在跑”，实际容器已僵死 - 挂载宿主机文件时，PowerShell 路径
C:\myapp\docker-compose.yml在 WSL2 内对应/mnt/c/myapp/docker-compose.yml，但 Compose 默认只认当前 shell 的 pwd，不会自动映射 - 最稳的做法：在 WSL2 终端里执行所有
docker compose命令，并把项目放在/home/<user>/</user>下（避免/mnt/性能损耗和权限问题）
真正卡住人的从来不是“服务没起来”，而是“服务显示起来了，但 API 返回 502、数据库连不上、健康检查一直失败”。这时候别只盯着 GUI 刷新，先确认 docker compose ps 的 Health 列、再用 config 对齐配置、最后进 WSL2 看真实路径——三步下来，80% 的“状态谜题”就解开了。
