CI中Go模块依赖管理的真实消耗点在于不当配置引发的连锁反应，包括go mod download频繁拉取、go build重复解析、golangci-lint过度扫描，导致构建时间翻倍、缓存失效和镜像体积膨胀。
CI 流程中 Go 模块依赖管理本身不直接消耗大量 CPU 或内存，但不当配置会引发 go mod download 频繁拉取、go build 重复解析、golangci-lint 过度扫描等连锁反应，最终导致构建时间翻倍、缓存失效、镜像体积膨胀——这些才是真实消耗点。
go.mod 和 go.sum 必须提交，且要保持“最小必要”
很多团队把 go.mod 当成自动生成的“元数据”，改完依赖不 go mod tidy 就提交，或让 CI 自行执行 go mod download。结果是：每次构建都触发完整依赖树解析，跳过本地缓存，反复下载相同模块（尤其在无 GOPROXY 的私有环境里）。
- 每次
go mod tidy后，手动检查go.sum是否新增了未预期的间接依赖（带// indirect的行），删掉长期不用的旧版本残留 - 禁止在 CI 脚本里写
go get或go mod download -x——这会绕过go.sum校验，还可能污染缓存 - 若项目含多个子模块（如
cmd/api、pkg/storage），每个子模块应有独立go.mod，避免顶层go mod tidy扫描整个代码树
GOPROXY 和 GOSUMDB 配置决定 80% 的网络与校验开销
默认 GOPROXY=https://proxy.golang.org 在国内常超时或返回 429；而关闭 GOSUMDB（设为 off）虽能跳过校验，却失去防篡改能力，CI 构建结果不可信。
- 企业级推荐组合：
GOPROXY=https://goproxy.cn,direct（国内可用） +GOSUMDB=sum.golang.org（不关，靠代理自动转发校验请求） - 若用私有代理（如 Athens），务必在 CI 环境中配置
GOPRIVATE=git.internal.company.com/*，否则私有模块仍会尝试走公共 proxy 导致失败 - GitLab CI / GitHub Actions 中，把
GOPROXY设为 job 级环境变量，而非全局 runner 设置——避免不同项目间 proxy 策略冲突
多阶段构建中复用 GOMODCACHE 是提速关键
Docker 构建时，每轮 FROM golang:1.21 都是全新环境，go build 前必须重下所有依赖。GOMODCACHE 默认在 /root/go/pkg/mod，不跨 stage 持久化就等于放弃缓存。
立即学习“go语言免费学习笔记（深入）”；
- 在 builder 阶段结尾加
COPY --from=0 /root/go/pkg/mod /root/go/pkg/mod（需显式多阶段引用）或使用 BuildKit 的cache-from挂载缓存目录 - 更稳妥的做法：把
GOMODCACHE显式指向一个固定路径（如/cache/mod），并在 CI 中挂载该路径为缓存卷（GitHub Actions 的actions/cache可缓存~/.cache/go-build和$GOMODCACHE） - 注意：
go clean -modcache绝对不能出现在 CI 脚本里——这是最常见的人为清缓存操作
golangci-lint 的依赖扫描必须隔离于构建流程
golangci-lint run 默认会加载所有 import 包的 AST，包括 vendor/ 和 internal/ 下未导出模块，极易触发冗余依赖解析，和 go build 争抢 GOMODCACHE 锁。
- 在
.golangci.yml中强制指定run: modules: false，禁用模块级分析，只做文件级 lint - 排除
vendor/、third_party/、generated/目录（不是靠exclude-dirs，而是用skip-dirs-use-default: false+ 显式skip-dirs） - 把 lint 步骤从构建阶段拆出，放在单独 job，并设置
cache: false（它不需要复用构建缓存，反而容易污染）
真正难的不是配对某个参数，而是让 go.sum 的哈希值、GOPROXY 的响应一致性、Docker 构建缓存路径三者对齐——任何一环错位，CI 就退回“每次都重来”的低效状态。线上故障往往不出现在报错那一刻，而出现在某次 go mod tidy 后少提交了一行 go.sum。
