必须显式设置GO111MODULE=on，因CI环境（如Jenkins、golang:alpine）易退化为GOPATH模式导致构建不可重现；需强制export、确保工作目录为项目根、配合go mod download与verify校验依赖完整性。
CI中GO111MODULE=on必须显式设置
Go 1.16+ 虽默认启用模块模式，但 CI 环境（如旧版 Jenkins Agent、golang:alpine 镜像、或工作目录在 $GOPATH/src 下）仍可能退化为 GOPATH 模式——此时 go build 会忽略 go.mod，拉取非锁定版本，导致构建不可复现。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 所有 CI 步骤开头强制执行
export GO111MODULE=on，不依赖 Go 版本默认行为 - 确保 CI 工作目录是项目根目录（含
go.mod），禁止在$GOPATH/src下运行构建 - GitHub Actions 中直接在
steps的env块里写：GO111MODULE: "on" - GitLab CI 中可在
variables或每个script开头加go env -w GO111MODULE=on
go mod download 和 go mod verify 缺一不可
go build 会静默下载缺失模块、跳过哈希校验，CI 中仅靠它无法发现被污染或篡改的依赖（比如代理缓存投毒、私有镜像被替换）。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 在构建前独立执行
go mod download，确保所有依赖可获取且版本与go.mod一致 - 紧接着运行
go mod verify；若失败必须中断流水线（它默认返回非零退出码） - 若使用私有代理（如 Athens），需额外配置
GOPROXY并验证其 TLS 证书有效性 - 避免把
go mod tidy放进 CI —— 它应只在本地提交前运行，并连同go.sum一起提交
GOSUMDB 和 GOPROXY 的取舍与配置
GOSUMDB=sum.golang.org 在 CI 中易因网络策略、DNS 不稳或防火墙超时失败；但设为 off 又等于放弃依赖完整性校验。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 生产 CI 中**不要设
GOSUMDB=off**，而是用GOSUMDB=off仅作临时调试 - 更稳妥的做法是：保留
GOSUMDB默认值，同时配置可信代理（如GOPROXY=https://goproxy.cn,direct），并确保代理服务 TLS 有效 - 国内环境优先用
https://goproxy.cn或https://proxy.golang.org，末尾加,direct保证私有模块直连 - 若必须禁用远程校验（如离线环境），应配合本地
sumdb镜像或人工校验go.sum内容一致性
Docker 多阶段构建中模块下载要分离
把 go mod download 和 go build 放在同一 FROM golang:xxx 阶段，会导致最终镜像体积膨胀（含完整 pkg/mod 缓存），且破坏构建层缓存复用逻辑。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 第一阶段（
builder）只做依赖下载：go mod download+go mod verify，然后 COPY 到下一阶段 - 第二阶段（
alpine或scratch）只 COPY 编译产物和必要资源，不带任何 Go 工具链或模块缓存 - 利用
docker build --cache-from复用前序构建的mod层，加速后续流水线 - GitLab CI 中可通过
cache: paths: [".go/pkg/mod"]缓存模块，但注意路径需与GOMODCACHE一致
go build 真正基于已验证的、确定的依赖快照执行。 
