go mod verify仅校验本地缓存与go.sum哈希是否一致，不访问远程源；要确认本地版本是否与远程仓库当前发布一致，需用go list -m -u all等命令主动查询proxy或vcs。
直接运行 go mod verify 无法核对本地与远程仓库的版本一致性——它只比对本地缓存和 go.sum，不接触远程源。 真正要确认“本地下载的版本是否和远程仓库当前发布的一致”，得靠组合命令 + 明确区分校验目标。
为什么 go mod verify 不是你要的答案
它只做一件事：用本地 $GOPATH/pkg/mod 缓存里的模块文件，重新计算哈希，再和 go.sum 里记录的哈希比对。只要缓存没坏、go.sum 没被手改，就过；它完全不访问 GitHub、proxy.golang.org 或任何远程地址。
- 即使远程仓库已删掉某个 tag（比如
v1.9.1），只要本地缓存还在、go.sum没更新，go mod verify依然会显示all modules verified - 如果别人 push 了新 commit 到同一 tag（即移动标签），
go mod verify也检测不到——因为哈希已随旧内容写死在go.sum里 - 它不告诉你“这个版本现在是否还存在”，只告诉你“我本地存的这份，和当初记录的一致”
真正能核对远程状态的命令组合
你需要让 Go 工具链重新从远程拉取元数据，而非依赖缓存：
- 运行
go list -m -u all：列出所有依赖及其最新可用版本（来自 proxy 或 vcs）。方括号里的是远程可获取的最新版，比如github.com/gin-gonic/gin v1.9.1 [v1.10.0]表示远程已有v1.10.0 - 运行
go list -m -f '{{.Version}} {{.Update}}' github.com/some/pkg：单独查某个模块，输出当前锁定版本和远程最新版（.Update字段为空表示无更新） - 加
-versions参数看全量 tag 列表：go list -m -versions github.com/gorilla/mux，这会真实请求 proxy，返回所有可用版本号
注意：这些命令受 GOPROXY 和 GOSUMDB 影响。若用私有代理或禁用校验和数据库（GOSUMDB=off），结果可能和公共生态不一致。
遇到校验和不匹配时，别急着 go mod tidy
当 go mod verify 失败，或 go build 报 checksum mismatch，常见诱因不是网络问题，而是环境混杂：
- 本地
GO111MODULE=auto且目录下有vendor/，Go 可能 fallback 到 vendor 模式，跳过go.sum校验 - Docker 构建时用了 Alpine 镜像但没装
git，导致私有模块无法 clone，转而用 proxy 下载了带 patch 的变体，哈希自然不同 - CI 流水线设置了
GOSUMDB=off，而本地没关，go.sum记录来源不一致 - 多人协作中有人手动编辑了
go.sum（比如删掉某行），下次go mod download就会补回，但内容已和原始不一致
最稳妥的清理方式是：go clean -modcache 清空缓存，再 go mod download 重拉，最后 go mod verify。不要跳过 download 直接 verify——那只是在验证一个空缓存的失败。
真正麻烦的从来不是命令怎么敲，而是搞清你在验证什么：是“本地副本是否被篡改”，还是“这个版本在远程是否还有效”。前者靠 go.sum，后者得连网问 proxy 或 vcs。
