如何在Golang中利用Docker Compose编排微服务 Go语言本地开发环境搭建-Golang-PHP中文网

docker compose中go服务的build.context必须指向含go.mod的目录，否则go build会失败；depends_on需配合healthcheck和代码层重试；开发应使用air热重载而非go run；goproxy等需通过args注入构建阶段。

如何在golang中利用docker compose编排微服务 go语言本地开发环境搭建

本地开发时，Go 服务镜像不能靠 go build 命令临时编译再塞进基础镜像——那样会丢失模块依赖和版本信息，导致运行时报 module github.com/xxx/yyy is not active 或找不到包。

正确做法是让 Docker 构建过程自己执行 go mod download 和 go build，这就要求 Dockerfile 所在目录（即 build.context）下必须存在 go.mod。否则 go build 会退化为 GOPATH 模式，或直接失败。

build: 下的 context 要设为服务代码根目录，不是项目根目录（除非两者重合）
如果 Go 服务在 ./svc/user，context 就得是 ./svc/user，且该路径下要有 go.mod
别用 build: . 然后靠 dockerfile 指定子路径——Docker 构建时仍以 context 为工作区，go mod 读不到上层的 go.mod

depends_on 只检查容器是否 启动成功，不检查端口是否可连、数据库是否 ready。常见现象是 Go 服务启动时 panic：dial tcp 172.20.0.3:5432: connect: connection refused，因为 PostgreSQL 容器还在初始化。

解决方法不是加 restart: on-failure，而是让 Go 服务自己做连接重试，或者加一层健康检查兜底：

在 docker-compose.yml 中为 DB service 加 healthcheck，例如 PostgreSQL 的 pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DB}
Go 服务的 depends_on 改成 condition: service_healthy
Go 代码里仍需实现连接池初始化重试逻辑——depends_on 是 compose 层的约束，不是网络层保障

把 go run main.go 写进 command 或 entrypoint，看似能热重载，实则每次文件变更都会触发容器重启，丢失状态、打断调试、且无法复用已下载的 go.sum 缓存。

Golang Lint

Golang 项目 lint 最佳实践与 golangci‑lint 配置——运行 linter、编辑 .golangci.yml、使用 nolint指令抑制警告。

下载

更稳的方式是：容器内只跑一个进程（如 air），由它监听文件变化并管理 go run 生命周期：

在 Dockerfile.dev 中装 air：RUN go install github.com/cosmtrek/air@latest
command 设为 air -c .air.toml，配置文件里指定 root 和 bin（避免每次重建二进制）
volumes 映射源码时，排除 node_modules、vendor、go/pkg 等非必要目录，否则 inotify 事件过多会导致 air 卡死