必须设goproxy=https://goproxy.cn,direct并验证生效，否则私有模块拉取失败；需确保shell子进程继承该环境变量，ci中须同时缓存$home/go/pkg/mod和~/.cache/go-build。
go mod download 总是卡在 proxy.golang.org 怎么办
这不是你网络差，而是 Go 默认直连 proxy.golang.org，该地址在国内 DNS 污染严重、TLS 握手常超时，go mod download 会卡在 “Fetching” 阶段几十秒甚至更久，最后报 context deadline exceeded 或 dial tcp: i/o timeout。
必须设 GOPROXY 并带 ,direct 后缀，否则私有模块（如 git.internal.company）会直接失败：
go env -w GOPROXY=https://goproxy.cn,direct- 验证是否生效：
go env GOPROXY应输出完整字符串，不是空或只含https://goproxy.cn - 别信“改了
go env -w就完事”——Shell 新开终端可能没继承环境变量，建议加到~/.bashrc或~/.zshrc并重载
CI/CD 中缓存不命中导致反复下载
CI 环境每次清空 $HOME/go 或只缓存 ~/.cache/go-build，go mod download 就永远从零开始拉取——因为模块缓存实际存在 $GOPATH/pkg/mod，不是构建缓存。
GitHub Actions 等平台必须同时缓存两个路径：
-
$HOME/go/pkg/mod（模块解压后树状结构） -
~/.cache/go-build（go build的编译产物缓存） - 不能只缓存后者——它不影响
go mod download行为 - 避免在 CI 脚本里写
go clean -modcache，这是人为废掉全部模块缓存
go build 缓存看似生效但实际没提速
go build 输出里看到 cached 不代表真快：它只表示某个包的编译结果被复用，但若 go.mod 有变更、GOOS/GOARCH 切换、加了 -ldflags，或 GOCACHE 已满（默认 4GB），旧缓存就会被 LRU 清掉。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
排查方法很直接：
- 加
-x参数运行：go build -x main.go，看输出里有没有cached字样 - 没看到就说明没命中——此时问题不在模块缓存，而在构建输入不稳定
- CI 中固定 Go 版本（如
1.23.0而非latest），不同 minor 版本可能生成不兼容的缓存 blob
checksum mismatch 是缓存污染还是镜像延迟
报 checksum mismatch 时，90% 不是网速问题，而是模块内容与 sum.golang.org 记录哈希不一致。常见于：
- 镜像源同步滞后（比如新 tag 刚推，
goproxy.cnCDN 还没刷新） - 本地
$GOPATH/pkg/mod缓存损坏（尤其之前用过GOSUMDB=off） - 自建代理未透传官方校验，或配置了
GOINSECURE导致跳过校验
临时调试可关校验：GOSUMDB=off go mod download，但上线前必须恢复；生产环境首选清理缓存：go clean -modcache 再重试。
真正难处理的是企业内网场景：既要加速公共模块，又不能把私有仓库地址暴露给外部代理。这时候 GONOPROXY 和分层 GOPROXY 配置比单纯换镜像重要得多——漏配一个私有域名，整个构建就卡死。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
