必须将go mod download放在copy . .之前，因为docker层缓存依赖输入一致性：go.mod/go.sum变更少，先复制并下载可长期复用缓存；若源码先复制，每次代码改动都会使后续依赖下载层失效。
Go模块依赖在K8s容器化中根本不会自动“在线缓存”——Docker构建阶段的go mod download结果只存在于构建镜像层里，K8s Pod启动时不会复用它；每次Pod重建都得重新下载依赖，除非你提前固化到镜像中。
为什么go mod download必须放在COPY . .之前
Docker层缓存生效的前提是：前面所有指令的输入没变。Go项目里go.mod和go.sum变更频率远低于源码，把它们复制后立刻执行go mod download，就能让这一步长期命中缓存。
- 错误写法：
COPY . .→RUN go mod download→ 每次改一行代码，整个依赖下载层就失效 - 正确顺序：
COPY go.mod go.sum ./→RUN go mod download→COPY . .→RUN go build - 如果
go.sum缺失或校验失败，go mod download会报错verifying github.com/xxx@v1.2.3: checksum mismatch，必须先本地go mod tidy再提交
多阶段构建中依赖缓存只保留在builder阶段
最终运行镜像（比如alpine或scratch）里根本没有$GOPATH/pkg/mod，也不可能运行go mod命令。所谓“缓存”，仅指构建时builder镜像那一层能复用。
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- builder阶段的
/root/go/pkg/mod目录会被完整缓存，但不会拷贝到最终镜像 - 别在final stage里试图
RUN go mod vendor——基础镜像没Go环境，命令根本不存在 - 如果用了
vendor目录，需在COPY . .之后、go build之前加RUN go mod vendor，且go build -mod=vendor
CI/CD里依赖下载慢？优先配GOPROXY而不是硬编码镜像
国内CI环境直连proxy.golang.org大概率超时，但直接换镜像源又容易被团队忽略更新。最稳的方式是在Dockerfile里声明环境变量。
- 推荐写法：
ENV GOPROXY=https://goproxy.cn,direct（逗号分隔支持fallback） - 避免写死
https://mirrors.aliyun.com/goproxy/——阿里云goproxy服务2025年已下线 -
GOSUMDB=off仅限私有模块且可信内网，生产环境不建议关闭校验 - 如果项目含私有Git模块（如
git.example.com/internal/lib），需额外配置git config --global url."https://token@github.com/".insteadOf "https://github.com/"
真正容易被忽略的是：K8s里initContainer没法帮你缓存go mod，因为init容器的文件系统不共享给主容器；想“在线缓存”，唯一靠谱路径就是把go mod download稳稳落在builder镜像层里，并确保go.mod足够稳定。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
