答案是go.mod和go.sum才是可迁移的依赖真相，$GOMODCACHE不可移植。Go模块依赖应通过go.mod与go.sum在目标环境重建，而非拷贝缓存目录；后者因版本、架构、路径差异易导致构建失败，正确做法是仅复制这两文件并在容器内执行go mod download或go build自动拉取。
容器间迁移不能直接拷贝 $GOMODCACHE
Go 模块依赖默认下载到 $GOMODCACHE（通常是 $HOME/go/pkg/mod），但这个目录**不是可移植的构建单元**。不同容器可能用不同 Go 版本、不同架构（amd64/arm64）、不同 GOOS/GOARCH，导致缓存中二进制或校验信息不兼容。直接 cp -r 或 tar 迁移该目录，大概率在目标容器里触发 go build 失败或 go mod download 重拉，甚至静默使用错误版本。
真正可迁移的是 go.mod 和 go.sum
这两个文件才是模块依赖的“唯一真相”。只要它们完整，目标容器执行 go build 或 go mod tidy 就能重建一致依赖。关键点：
-
go.mod必须包含所有直接和间接依赖的精确路径与版本（含replace和exclude） -
go.sum必须存在且未被篡改——它校验每个模块的哈希，缺失或不匹配会导致go build拒绝运行 - 如果项目用了私有模块（如
git.example.com/internal/lib），需确保目标容器已配置GOPRIVATE=git.example.com/*，否则go mod tidy会卡在认证失败
Docker 构建时别依赖宿主机 go mod cache
多阶段构建中常见错误：在 builder 阶段 COPY 宿主机的 $GOMODCACHE 进镜像。这既没必要又危险：
- 官方
golang:1.24.3等镜像已内置空缓存，go mod download会自动填充 - 宿主机缓存可能含本地
replace路径（如replace example.com/lib => /home/user/lib），进容器后路径失效，go build报cannot find module providing package - 正确做法是：只 COPY
go.mod+go.sum+ 源码，在构建阶段跑go mod download（或让go build自动触发）
CI/CD 中跨节点复用缓存要走远程方案
想避免每次构建都重下依赖？别传 $GOMODCACHE，改用：
立即学习“go语言免费学习笔记（深入）”；
- GitHub Actions：用
actions/cache缓存~/go/pkg/mod，但必须加 key 带 Go 版本 + OS +go.modhash，否则混用出错 - GitLab CI：用
cache:paths配$GOPATH/pkg/mod，同样需key: "$CI_JOB_NAME-$GO_VERSION-$(sha256sum go.mod | cut -c1-8)" - 自建 registry：用
athens或goproxy.cn作为代理，所有容器统一设GOPROXY=https://your-athens/proxy，缓存由服务端维护
本地开发机和生产容器之间，最稳的迁移动作就两步：确保 go.mod 和 go.sum 提交进 Git；容器内只靠这两个文件重建依赖。任何绕过它的“解压包搬运”，都在给后续的 go build 埋雷。
