多阶段构建中go mod download总重下，因各阶段根文件系统隔离，$gopath/pkg/mod不共享；须用buildkit的--mount=type=cache,id=gomod,target=/go/pkg/mod挂载复用缓存。
为什么多阶段构建里 go mod download 总是重下一遍？
因为每个 FROM 阶段都是全新镜像，上一阶段的 $GOPATH/pkg/mod 或 ~/.cache/go-build 完全不可见。Docker 构建缓存只对同一层生效，而 go mod download 又没默认复用本地缓存路径——它每次都在干净根文件系统里跑，自然重拉所有模块。
用 --mount=type=cache 复用模块下载缓存
Docker BuildKit 的 cache mount 是目前最轻量、最可靠的解法，不用改 Go 代码，也不依赖外部 registry 或私有 proxy。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 必须启用 BuildKit：
DOCKER_BUILDKIT=1 docker build ... - 在
go mod download所在阶段加挂载：RUN --mount=type=cache,id=gomod,target=/go/pkg/mod go mod download -
id=gomod是缓存键名，同一构建中多个阶段用相同id才能共享 - 不要写成
target=~/.cache/go-build——go mod download不读那里，只认GOPATH/pkg/mod
构建阶段之间如何安全传递 go.sum 和 go.mod？
不能靠 COPY 整个 src 目录进 builder 阶段再跑 go mod download，那样会触发校验失败：Go 要求 go.sum 必须与当前 go.mod 精确匹配，且不允许在未声明 module 的目录里执行该命令。
- 确保
go.mod和go.sum在构建上下文根目录，且权限为普通文件（不是 symlink） - 在 builder 阶段先
COPY go.mod go.sum ./，再RUN go mod download，顺序不能反 - 如果项目用了 replace 或 indirect 依赖，
go.sum缺失会导致下载失败，别删它
什么时候该用 GOPROXY 而不是本地缓存？
本地 cache mount 解决的是“重复下载”，但解决不了“下载慢”或“私有模块不可达”。这时候才需要 proxy。
- 国内环境建议设
GOPROXY=https://proxy.golang.org,direct或国内镜像（如https://goproxy.cn） - 私有模块必须配
GOINSECURE或用支持认证的 proxy，否则go mod download直接报checksum mismatch - 注意：
GOPROXY不影响 cache mount 的有效性，两者可共存；但 proxy 设置错误会导致缓存完全失效——因为下载失败后 cache 不会被写入
go.sum 文件缺失或挂载路径写错成 /root/go/pkg/mod（非 root 用户时路径不对），结果看着命令跑过去了，其实啥都没缓存住。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
