根本原因是goproxy未正确配置且docker构建缓存未合理利用：必须前置copy go.mod/go.sum并独立执行go mod download，同时显式设置env goproxy=https://goproxy.cn,direct以避免直连超时及私有模块拉取失败。
Go模块依赖下载慢，根本原因不是网络差，而是没用对缓存和代理——直接改Dockerfile和构建命令就能立竿见影。
go mod download 层必须前置且独立
Docker构建缓存只在指令完全一致时命中。如果把 COPY . . 放在 go mod download 前面，哪怕只改了一行代码，整个依赖下载层就失效，每次重下。
- 必须先
COPY go.mod go.sum ./，再RUN go mod download - 不要合并操作，比如写成
COPY . . && go mod download—— 这会破坏缓存粒度 - 确保
go.sum存在且未被.dockerignore误删（常见坑：忽略*.sum或**/go.sum）
GOPROXY 必须显式设置，不能靠环境默认
CI/CD环境里，Docker守护进程通常不继承宿主机的 GOPROXY，不设就直连官方 proxy.golang.org，国内超时或限速是常态。
- 在构建阶段开头加
ENV GOPROXY=https://goproxy.cn,direct（或https://proxy.golang.org,direct若境外环境） - 避免只设
GOPROXY=https://goproxy.cn—— 缺少direct会导致私有模块无法拉取 - 不推荐用
--build-arg动态传入，容易漏配或CI脚本未透传
多阶段构建中，gomod cache 目录不共享但可复用
构建阶段的 $GOMODCACHE 默认在镜像层内，下一阶段不会自动继承。但你不需要手动挂载，关键是让第一阶段的下载层稳定命中。
- 只要
go.mod和go.sum不变，RUN go mod download就永远走缓存 - 不要试图在构建阶段挂载宿主机
/tmp/go-mod-cache—— CI环境路径不可靠，且违反不可变构建原则 - 若用 Makefile 或自定义构建脚本，确保
docker build命令没加--no-cache或--pull（后者会强制更新 base image，间接清空缓存）
go mod tidy 和 vendor 不是优化项，反而是风险点
有人以为 go mod tidy 能“清理冗余依赖”从而加速，实际它会触发重新解析、下载、校验，反而增加不确定性；vendor 则让 Dockerfile 失去缓存优势，且增大上下文体积。
- 除非项目强要求锁定所有 transitive 依赖（如金融类审计场景），否则别用
go mod vendor -
go mod tidy应仅在开发提交前本地运行，不该放进 Dockerfile - CI 构建失败若报
checksum mismatch，优先检查go.sum是否被意外修改，而不是加-dirty参数绕过
真正卡住构建的，往往不是某条命令本身慢，而是缓存链断裂后被迫重跑整条依赖流水线。最值得花时间确认的，是 go.mod 的变更频率是否真的低于代码变更频率——如果不是，那问题不在构建，而在模块管理策略本身。
