go mod download 拿不到最新版是因代理缓存未及时同步，非本地缓存或配置问题；需用 timestamp 参数、@main 或 GOPROXY=direct 强制回源，并通过 .info/.mod 文件时间戳和 go mod verify 验证实际版本。
代理缓存失效时，go mod tidy 仍可能拉到旧版本依赖——这不是网络慢，而是代理层返回了过期缓存响应。
为什么 go mod download 拿不到最新版？
国内主流 Go 代理（如 https://goproxy.cn）本身带 CDN 和本地缓存机制。当上游模块发布新版本后，代理节点未必实时同步，尤其对非热门模块或刚发布的 tag，缓存 TTL 可能长达数小时。此时 go list -m -u all 显示有更新，但 go mod download 仍拉取旧版，go get -u 也无反应。
- 典型现象：
go list -m -u github.com/some/pkg输出github.com/some/pkg v1.2.3 [v1.2.4]，但go get github.com/some/pkg@latest仍得v1.2.3 - 不是本地缓存问题：
go clean -modcache无效，因为问题在代理侧 - 不是 GOPROXY 配置错误：
go env GOPROXY返回正确地址，且curl -I https://goproxy.cn/github.com/some/pkg/@v/list能返回 200
强制刷新代理缓存的三种实操方式
绕过代理缓存，直接命中最新版本元数据或模块内容：
- 加
timestamp查询参数触发代理强制回源：go get github.com/some/pkg@v1.2.4+incompatible?timestamp=20260803（时间戳需变化，否则仍走缓存） - 用
@master或@main强制拉取最新 commit（仅限 git 仓库）：go get github.com/some/pkg@main，再手动改go.mod中的版本号 - 临时切换为
direct单独拉取该模块：GOPROXY=direct go get github.com/some/pkg@v1.2.4—— 注意必须确保该模块可直连（如 GitHub 公共仓库），私有库会失败
GOPROXY 后缀加 ,direct 不等于“实时”
很多人以为配置了 GOPROXY=https://goproxy.cn,direct 就能 fallback 到最新源，其实不然：
-
direct仅在代理返回 404 或 5xx 时触发，而缓存命中是 200，根本不会 fallback - 代理返回的
/@v/v1.2.4.info或/@v/v1.2.4.mod若已缓存，direct完全不参与 - 真正起作用的是
GONOPROXY：对明确需要跳过代理的模块，必须显式加入，例如：go env -w GONOPROXY="github.com/some/pkg"
验证是否真拿到最新版而非缓存副本
别只信 go list 输出，要查实际下载内容：
- 看缓存目录下模块的
.info文件时间戳：ls -l $GOMODCACHE/github.com/some/pkg@v1.2.4.info，对比发布时间 - 检查
.mod文件内容是否含预期变更：cat $GOMODCACHE/github.com/some/pkg@v1.2.4.mod | head -n 5 - 运行
go mod verify github.com/some/pkg@v1.2.4，若校验通过但行为异常，大概率是代理返回了旧版 checksum
最隐蔽的坑在于：代理缓存的不只是 zip 包，还包括 .info、.mod、.zip 三类文件，它们可能不同步更新。遇到版本滞后，优先怀疑代理缓存一致性，而不是重装 Go 或清本地 pkg/mod。
