部署成功需确认服务真正就绪：docker compose ps 显示 healthy 最可靠；仅 Up 状态需查日志、验证网络互通（如 telnet namesrv 9876）、检查 depends_on 是否配合 condition: service_healthy，并确保环境变量注入正确、挂载路径共享且换行符为 LF。
只要 docker compose up 没报错、所有服务状态变成 healthy 或持续运行（Up X minutes），且你能访问到对应端口的服务，就基本算部署成功了——但很多“看似成功”的项目，其实卡在健康检查、依赖时序或网络连通性上，得靠具体手段验证。
怎么看服务是不是真起来了，不是光“没退出”
Docker Desktop 的 UI 界面只显示容器是否在运行，不反映应用层是否就绪。比如一个 Web 服务容器启动了，但数据库连接失败、配置加载异常、端口被占用，它可能一直在重启或卡在初始化阶段。
- 用
docker compose ps查看每个服务的STATUS列：出现healthy最可靠；若只有Up，要继续查日志 - 对关键服务加
healthcheck配置（如 HTTP GET /health 或curl -f http://localhost:8080/actuator/health），否则 Compose 默认不判断“健康” - 避免只看 UI 的“Running”状态——UI 不刷新 healthcheck 结果，必须用 CLI 命令确认
怎么确认多服务之间能互相访问
容器内网络互通 ≠ 应用能连上，常见问题包括服务名解析失败、端口未暴露、启动顺序错乱。
- 进某个容器执行
ping namesrv或telnet namesrv 9876（需先装telnet工具），验证 DNS 解析和端口可达性 - 确保
depends_on配合condition: service_healthy使用，否则depends_on只等容器启动，不等服务就绪 - 检查
networks是否共用同一自定义网络（如rmq-net），默认bridge网络下跨服务通信可能受限
为什么浏览器能打开，但 API 调不通
本地浏览器访问 http://localhost:8098 成功，不代表后端服务真的处理请求——可能是反向代理返回了 200，但上游 502；也可能是 CORS 或路径前缀没配对。
- 用
curl -v http://localhost:8098/api/v1/clusters直接测后端接口，看响应体和真实 HTTP 状态码 - 查目标服务日志：
docker compose logs rmqconsole，重点找Connection refused、UnknownHostException、Failed to connect to namesrv - 确认环境变量是否生效：比如
NAMESRV_ADDR: "namesrv:9876"在容器内是否被正确注入（进容器执行env | grep NAMESRV）
Windows 下特别容易漏掉的三件事
Windows + Docker Desktop 组合有隐藏行为，不注意会导致“开发机跑通，换台机器就挂”。
-
volumes路径必须在 Docker Desktop 的 File Sharing 设置里勾选（默认只共享C:\Users），否则挂载为空目录，配置文件或数据目录实际没进去 - 换行符问题：Windows 编辑的
broker.conf若含\r\n，Linux 容器里某些 Java 启动脚本会解析失败，建议用 VS Code 设置保存为LF -
docker compose up启动后别立刻关终端——PowerShell/CMD 关闭会导致前台进程被 SIGINT 中断，容器退出；要用docker compose up -d
真正难的不是让容器跑起来，而是让它们按预期协作。健康检查、网络拓扑、环境变量注入、文件挂载路径这四点，任何一个出偏差，都会导致“看起来在运行，实际上不能用”。尤其在 Windows 上，路径共享和换行符这种细节，最容易在迁移时突然爆发。
