Docker构建Go服务镜像运行测试时报MongoDB服务选择超时错误

Docker镜像构建阶段执行RUN指令时，会启动一个隔离的临时构建容器，所有命令都在这个临时容器内部运行，拥有独立的网络命名空间：

• 你配置的连接地址127.0.0.1:27017在构建容器内指向容器自身的回环地址，这个临时容器里根本没有运行Mongo服务，自然会报连接拒绝。
• 本地直接跑测试能通过，是因为本地环境的127.0.0.1指向你的宿主机，docker-compose已经把Mongo的27017端口映射到宿主机上，所以能正常连通。
• 镜像构建的默认网络和你docker-compose启动Mongo用的网络是完全隔离的，构建阶段的容器默认访问不到compose里启动的其他服务。

额外提醒：就算你跳过构建阶段的测试把镜像做出来，后续直接启动微服务容器用127.0.0.1也连不上Mongo——运行阶段的微服务容器同样有独立网络栈，127.0.0.1只会指向微服务容器自身。

按推荐优先级排序：

• 方案1（推荐）：构建阶段移除对外部服务的依赖
  镜像构建的核心职责是编译产物、打包镜像，不应该耦合数据库这类外部依赖。把Dockerfile里的RUN go test -v /go/src/app/...行删掉，数据库相关的集成测试放到独立流程执行：
  1. 先通过docker-compose启动Mongo
  2. 在本地直接执行go test -v ./...跑测试，或者在CI流程中启动一个和Mongo同网络的临时Golang容器跑测试
     后续微服务容器化运行时，把微服务也加到同一个docker-compose配置里，连接Mongo的地址把127.0.0.1换成compose里的服务名mongodb即可，也就是连接串改成mongodb://user:password@mongodb:27017/microservices，docker-compose会自动做服务名的DNS解析。
• 方案2：临时指定构建网络为host模式（仅适合本地调试用）
  如果确实要在构建阶段执行测试，构建镜像时加上--network=host参数，让构建容器直接共享宿主机的网络栈，这时候构建容器内的127.0.0.1就指向宿主机，可以连通映射到宿主机的Mongo端口：

  docker build --network=host -t authsvc .
  

  注意这个方案在Windows/macOS版本的Docker Desktop上存在兼容性问题，且会让构建流程强依赖本地环境，不适合生产构建流程使用。

内容的提问来源于stack exchange，提问作者Laterneman