go mod download 在 CI 中反复拉包是因为每次执行都重新解析 go.sum 并下载 module zip 到 $GOCACHE，而 CI 环境通常不持久化 $GOCACHE 和 $GOPATH/pkg/mod 两个目录，导致无法复用缓存；必须同时挂载二者且确保权限匹配。
go mod download 为什么在 CI 流水线里反复拉包？
因为 go mod download 默认不复用本地缓存，每次执行都重新解析 go.sum 并下载 module zip 到 $GOCACHE（非 $GOPATH/pkg/mod），而多数 CI 环境是干净容器或临时 workspace，$GOCACHE 不持久化 → 每次都重下。
这不是 bug，是设计使然：Go 的模块缓存分两层——$GOCACHE 存已校验的 zip 包（供 build/link 复用），$GOPATH/pkg/mod 存解压后的源码（供 go list、go mod graph 等读取）。CI 中若只挂载 pkg/mod 却没挂载 $GOCACHE，go mod download 就无法跳过校验步骤。
- 必须同时挂载
$GOCACHE和$GOPATH/pkg/mod，且路径需与 CI runner 用户权限匹配（如用root启动但 job 以非 root 运行，会因权限拒绝写入） -
go mod download -json输出可解析，但别依赖它做“增量判断”——Go 不保证输出顺序或字段稳定性，仅用于调试 - 别在
go mod download后手动cp -rpkg/mod到其他路径——符号链接会断，go工具链会 fallback 到重新下载
如何让私有 registry 的模块也走多级缓存？
Go 官方不支持“L1 内存缓存 + L2 私有 proxy”，但可通过 GOPROXY 链式配置模拟：把企业级 proxy（如 Nexus、Artifactory、ghcr.io/your-org/go-proxy）设为第一级，再配一个本地反向代理（如 goproxy 或自建 nginx）作第二级，拦截高频 module 请求。
关键点不在“多级”，而在“可控失效”：私有模块更新后，go mod tidy 不会自动刷新 proxy 缓存，必须人工触发 proxy purge 或依赖 proxy 的 TTL 配置（如 Nexus 的 “Cache Expiration” 设为 1h，而非默认 0 表示永不过期）。
立即学习“go语言免费学习笔记（深入）”；
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
-
GOPROXY=https://proxy.yourcorp.com,https://proxy.golang.org,direct—— 注意逗号分隔，direct必须在末尾，否则私有模块会 fallback 到公网 - 若 proxy 返回 404，Go 会继续尝试下一个；但若返回 503 或超时，默认不 fallback，需显式加
GONOPROXY=*.yourcorp.com强制直连（仅限可信内网） - 私有模块的
go.mod若含replace指向本地路径（如replace github.com/your-org/lib => ./lib），CI 中该路径不存在 → 直接失败，必须提前cp或用go mod edit -replace动态替换
流水线中 go build 为何仍卡在 dependency resolve？
不是没缓存，而是 go build 在构建前会隐式执行 go mod download 校验依赖完整性，哪怕你刚跑过 go mod download。只要 go.sum 被修改（如 go get 新版本）、或 GOOS/GOARCH 变更（跨平台交叉编译）、或 $GOCACHE 被清空，它都会重走校验流程。
真正省时间的是 $GOCACHE 中的已编译归档（.a 文件），不是 module zip。所以即使 go mod download 快了，go build 仍可能慢——因为没复用之前编译产物。
- 确保 CI 中
GOOS、GOARCH、CGO_ENABLED与本地开发一致，否则$GOCACHE中的.a文件不可复用 -
go build -toolexec="gcc" -ldflags="-s -w"这类参数会改变 build hash，导致缓存 miss，除非所有 job 固定使用同一套 flags - 别用
go clean -cache清理 CI 缓存——它删的是$GOCACHE，不是pkg/mod；清理后者要用go clean -modcache，但通常不应在流水线中执行
gomod cache 与构建缓存（如 BuildKit）能共存吗？
能，但必须分层隔离：gomod 缓存（$GOCACHE + pkg/mod）是 Go 工具链原生行为，构建缓存（Docker BuildKit / GitHub Actions cache）是外部系统行为，二者不感知对方。
常见错误是把 pkg/mod 当作“构建产物”放进 Docker layer 缓存——这会导致镜像体积暴增（几十 MB 到几百 MB），且每次 go mod download 都污染 layer hash。正确做法是：在构建阶段前用 go mod download 预热 $GOCACHE，再 COPY 源码，最后 go build；pkg/mod 永远不进镜像。
- Dockerfile 中避免
COPY . .后立即go mod download——应先COPY go.mod go.sum .，再go mod download，最后COPY . .，利用 BuildKit 的 layer caching - GitHub Actions 的
actions/cache应分别缓存$GOCACHE和$GOPATH/pkg/mod，key 里必须含go version和go.sum checksum，否则不同 Go 版本或依赖变更时会误命中 - BuildKit 的
cache-from对 gomod 无效——它只缓存 RUN 指令输出，不理解 Go 的缓存路径语义
