go mod download 缓存失效典型表现为ci日志反复出现“downloading”、构建时间浮动超90秒或go build卡在依赖解析；主因是goproxy未配direct、$gopath/pkg/mod未持久化缓存、误执行go clean -modcache或go.mod未提交。
go mod download 缓存失效的典型表现
CI日志里反复出现 downloading github.com/some/pkg v1.2.3，构建时间每次浮动超过90秒，或者 go build 阶段卡在依赖解析——这基本不是网络问题，而是模块缓存没复用。常见诱因包括：
• GOPROXY 没生效（比如只设了 https://goproxy.cn 却漏掉 ,direct）
• CI工作空间每次从头创建，$HOME/go/pkg/mod 目录未挂载或未缓存
• 流水线里误执行了 go clean -modcache
• go.mod 文件没提交，导致CI拉取的是空依赖树，触发全量下载
必须同时缓存的两个路径
只缓存 $GOCACHE（编译对象）而忽略 $GOPATH/pkg/mod（模块源码），等于只装了发动机不给油——go build 能快，但 go mod download 依然慢。实际配置时：
• GitHub Actions：用 actions/cache@v4 分别缓存 ${{ env.HOME }}/go/pkg/mod 和 ${{ env.HOME }}/.cache/go-build
• GitLab CI：在 cache: 下定义两个 paths，并确保 key 包含 go.sum 的 SHA256 值
• Docker 构建：把 /home/runner/go/pkg/mod 和 /home/runner/.cache/go-build 设为 volume 挂载点，避免 layer 重建清空缓存
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
GOPROXY 配置错一个字符就白忙
GOPROXY=https://goproxy.cn,direct 中的 ,direct 不可省略，否则私有模块（如 git.internal.company/project）会被代理拦截，报 module not found 或 404。CI中必须用 go env -w GOPROXY=... 设置，而非 shell export——后者在下一个 job step 就失效。验证方式不是本地跑 go env，而是在 CI 日志里加一行：go env | grep -E 'GO111MODULE|GOPROXY|GOSUMDB'
输出必须是：GO111MODULE="on"GOPROXY="https://goproxy.cn,direct"GOSUMDB="sum.golang.org"
go build 缓存命中的关键信号
运行 go build -x 看输出，真正命中缓存时会出现：
• cd $WORK 没出现（说明没新建临时编译目录）
• 有类似 cached github.com/some/pkg 的行
• 没有 mkdir -p 或 cp 大量 .a 文件的日志
如果看到 cd /tmp/go-build* 或大量 gccgo、compile 命令，说明缓存完全没起作用。此时要查：
• GOOS/GOARCH 是否在不同 job 间切换（比如先 build linux/amd64，再 build darwin/arm64）
• -ldflags 参数是否每次动态生成（如含时间戳），导致哈希值总变
• GOCACHE 目录是否被设为 off 或权限拒绝写入
go mod download 必须作为独立步骤提前执行，而不是指望 go build 自动触发——后者失败即中断，根本不会留机会给你看日志。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
