Go Workspace多模块下如何为各项目单独构建Docker容器
Docker构建时找不到Common模块的核心原因是：默认构建上下文为执行docker-compose命令的当前目录（即Project1/Project2目录），上层目录的Common模块、go.work工作区配置文件不在上下文范围内，构建过程无法访问这些文件，自然无法解析依赖。
以下是两种可落地的实现方案，优先推荐第一种，完全适配现有Go Workspace的开发逻辑，无需改动业务代码。
方案1：调整构建上下文到Workspace根目录（推荐）
不需要调整现有代码目录结构，仅修改docker-compose配置和Dockerfile的路径逻辑即可。
第一步：修改对应项目的
docker-compose.yml构建配置
把原有的默认构建上下文（当前项目目录）改成Workspace根目录，同时明确指定Dockerfile的路径，以Project1为例：services: project1: build: context: ../ # 构建上下文指向Workspace根目录，可访问所有同级目录文件 dockerfile: Project1/Dockerfile # 指定当前项目Dockerfile的相对路径 # 其余端口映射、环境变量、卷挂载等配置保持原有内容不变Project2的配置逻辑完全一致，仅需把dockerfile字段值改成
Project2/Dockerfile即可。第二步：调整项目Dockerfile适配新的构建上下文
由于构建上下文切换到了Workspace根目录，Dockerfile内的文件拷贝路径需要对应调整，推荐用多阶段构建减小最终镜像体积，以下是Project1可用的Dockerfile示例：# 构建阶段：用官方Go镜像编译二进制 FROM golang:1.23-alpine AS builder WORKDIR /build # 先拷贝工作区配置、各模块go.mod文件，最大化利用Docker构建缓存 COPY go.work ./ COPY Common/go.mod Common/ COPY Project1/go.mod Project1/ # 提前下载依赖，go.mod无变更时该步骤会直接走缓存 RUN go mod download # 拷贝全部源码 COPY Common/ Common/ COPY Project1/ Project1/ # 编译静态二进制文件，避免运行阶段依赖系统库 RUN CGO_ENABLED=0 GOOS=linux go build -o /app-bin ./Project1/ # 运行阶段：用轻量Alpine镜像减小体积 FROM alpine:3.20 WORKDIR /app COPY --from=builder /app-bin ./ # 按项目实际端口修改，示例为8080 EXPOSE 8080 CMD ["./app-bin"]Project2的Dockerfile仅需把拷贝go.mod、源码、编译路径里的
Project1替换为Project2，二进制输出名称按需调整即可。第三步：优化构建速度（可选但建议做）
在Workspace根目录新建.dockerignore文件，排除不需要进入构建上下文的文件，避免上下文过大拖慢构建速度：**/.git **/*.log **/tmp **/.idea **/.vscode # 构建Project1时可排除Project2目录，反之同理，进一步缩小上下文体积 Project2/
配置完成后，直接在对应项目目录下执行docker-compose up -d即可正常构建，Go编译时会自动识别拷贝进去的go.work配置，和本地开发的依赖解析逻辑完全一致，不会再报Common模块找不到的错误。
方案2：Common模块推送到Git仓库替换本地依赖
如果不想调整构建上下文，可以把Common模块作为独立的Go模块推送到私有Git仓库，通过Go模块的版本管理机制拉取依赖：
- 给Common模块初始化Git仓库，打版本tag后推送到你的私有Git服务
- 在Project1、Project2的
go.mod文件中添加replace规则，把本地Common依赖替换为远程仓库地址：// 替换成你自己的模块路径和仓库地址 replace example.com/common => git.your-domain.com/common v1.0.0
这种方式不需要修改Docker配置，缺点是每次Common模块有修改都需要提交代码、打tag推送，本地调试时还要切回本地replace配置，流程比方案一繁琐，适合Common模块已经稳定、很少迭代的场景。
内容的提问来源于stack exchange，提问作者Hamza Hameed
