根本原因是docker构建缓存机制与go.mod变更不匹配：若copy . .在go mod download之前，源码任意改动（如时间戳变化）都会使整个上下文失效，导致依赖层无法复用；正确做法是单独copy go.mod和go.sum并立即run go mod download，同时显式设置goproxy环境变量。
为什么 go mod download 会在构建阶段反复失败
根本原因不是网络抖动，而是 Docker 构建缓存机制与 go.mod 文件变更不匹配。当你在 COPY . . 之后才运行 go mod download，Docker 无法复用上一次的依赖层——哪怕 go.mod 没变，只要源码目录有任意文件改动（比如 main.go 时间戳更新），整个构建上下文就失效，go mod download 就会重跑，且每次都在一个干净的容器里从零拉取。
- 把
COPY go.mod go.sum ./单独作为一层，并紧接RUN go mod download，让这一步能被缓存 - 务必同时复制
go.sum，否则go mod download可能因校验失败而中断 - 避免在
go mod download后执行go mod verify——它不提供额外安全收益，反而增加失败概率；go mod download本身已做校验
如何让 GOPROXY 在多阶段构建中稳定生效
GOPROXY 环境变量必须在 go mod download 执行前就设好，且不能只设在 builder 阶段开头——Docker 构建时每个 RUN 是独立 shell，环境变量不跨指令继承。
Go语言（Golang）1.26.0
下载
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
- 在
RUN命令里显式设置：RUN GOPROXY=https://goproxy.cn,direct go mod download - 不要用
ENV GOPROXY=...再跟RUN go mod download，因为ENV不影响前一个RUN的环境 - 如果公司内网有私有代理（如 Nexus Go Proxy），直接写死地址比用
direct更可靠：RUN GOPROXY=http://nexus.internal:8081/repository/goproxy/ go mod download
go mod vendor 是否值得在 Kubernetes 部署中启用
绝大多数情况下不推荐。vendor 目录会显著增大构建上下文体积，拖慢 CI 上传和 Docker daemon 解压速度，且掩盖了真实依赖版本问题。
- 仅当你的镜像构建环境完全离线（无任何外网访问能力）时才考虑
go mod vendor - 若只是想规避公共代理不稳定，优先用
GOPROXY+go.sum锁定，而不是引入 vendor - 一旦启用 vendor，必须确保
go build -mod=vendor，否则 Go 仍会去拉远程模块，导致行为不一致
CI 中并行构建多个 Go 服务时的依赖下载冲突
多个构建任务共享同一台 runner 的 $GOMODCACHE 目录时，go mod download 可能因并发写入损坏缓存，表现为 checksum mismatch 或 invalid version。
- 在 CI 脚本开头清空或隔离缓存：
export GOMODCACHE=$(mktemp -d) - 或者改用构建参数传递缓存路径：
docker build --build-arg GOMODCACHE=/tmp/modcache -t app .，并在 Dockerfile 中ENV GOMODCACHE=${GOMODCACHE} - 注意：Alpine 镜像默认没有
mktemp，若用 Alpine 作 builder，需先RUN apk add --no-cache util-linux
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
