CI/CD中必须显式启用GO111MODULE=on、执行go mod download和go mod verify校验、禁用go.sum自动更新、分离Docker多阶段构建中的模块下载。
Go模块在CI/CD中必须显式启用 GO111MODULE=on
默认情况下，Go 1.16+ 虽已默认开启模块模式，但某些 CI 环境（如旧版 Jenkins Agent、Docker 官方 golang:alpine 镜像）仍可能因环境变量未设或工作目录在 $GOPATH 内而退化为 GOPATH 模式，导致 go build 忽略 go.mod 或拉取错误版本。
实操建议：
- 所有 CI 步骤开头强制设置
GO111MODULE=on，不依赖 Go 版本默认行为 - 避免在
$GOPATH/src下运行构建；CI 工作目录应为项目根（含go.mod） - 若使用 GitHub Actions，直接在
steps中写：env: GO111MODULE: "on"
go mod download 和 go mod verify 应作为独立 CI 步骤
仅靠 go build 不足以验证依赖完整性——它会静默下载缺失模块，跳过校验哈希。CI 中漏掉显式校验，可能让被篡改的依赖（如 proxy 缓存污染、恶意镜像）进入构建产物。
实操建议：
- 在构建前执行
go mod download，确保所有依赖可获取且版本锁定 - 紧接着运行
go mod verify；失败时立即中断流水线（返回非零码） - 若使用私有模块代理（如 Athens），需额外配置
GOPROXY并验证其 TLS 证书有效性
CI 构建时禁用 go.sum 自动更新：设置 GOSUMDB=off 或严格校验
默认 GOSUMDB=sum.golang.org 依赖外部服务，在 CI 中可能因网络策略、防火墙或 DNS 不稳定导致超时失败；但盲目设 GOSUMDB=off 又会失去校验能力。
实操建议：
- 生产级 CI 推荐保留
GOSUMDB，通过timeout包裹命令或重试机制应对临时故障 - 若必须关闭校验（如离线环境），须同步设置
GOSUMDB=off并确保go.sum已提交且受代码审查约束 - 禁止在 CI 中运行
go mod tidy -v或任何修改go.mod/go.sum的命令——这会导致构建不可重现
Docker 多阶段构建中 go mod download 应与构建分离
常见错误是把 go mod download 放进最终镜像的构建阶段，导致二进制镜像体积膨胀（缓存的模块文件残留）、重复下载、无法复用依赖层。
实操建议：
- 第一阶段（
builder）专门做依赖下载：FROM golang:1.22-alpine AS builder WORKDIR /app COPY go.mod go.sum ./ RUN go mod download
- 第二阶段 COPY 源码后直接构建，不重复
go mod download - 最终镜像只包含二进制和必要 runtime 依赖，不带
go工具链或模块缓存
go mod verify，就多一分线上行为漂移的风险。 
