which go 和 go env goroot 不一致必然导致模块拉取出错：若 which go 返回 /usr/local/go/bin/go 而 go env goroot 显示 /home/user/sdk/go，说明二进制与标准库路径错配，会静默加载旧工具链、复用错误缓存，引发版本不一致或校验失败。
which go 和 go env GOROOT 不一致，模块拉取必然出错
这是最常被忽略的前置问题：如果 which go 返回 /usr/local/go/bin/go，但 go env GOROOT 显示 /home/user/sdk/go，说明 Go 二进制和它认定的标准库路径根本不是同一套。这种错配会导致 go get、go build 等命令静默读错缓存、加载旧工具链，甚至拉取到错误版本的模块。
- 先运行
brew list go（macOS）、dpkg -l | grep golang（Ubuntu）或choco list go（Windows Chocolatey），确认安装来源 - 检查所有 shell 配置文件：
~/.zshrc、~/.bash_profile、/etc/profile，删掉含GOROOT=的行 - 执行
unset GOROOT后再跑go env GOROOT，应返回自动探测路径（如/usr/local/go），而非你手动设过的值
go clean -modcache 不够，残留的 $GOPATH/pkg/mod 才是罪魁祸首
go clean -modcache 只清掉模块下载缓存，但不会动 $GOPATH/pkg/mod 下已解压、校验、重写 go.sum 的实际依赖副本。这些文件一旦残留，go get github.com/xxx/yyy@v1.2.3 可能跳过下载，直接复用旧内容，导致版本不一致、校验失败甚至 panic。
- 手动彻底清理：运行
rm -rf $(go env GOPATH)/pkg/mod - 注意：这会清空所有已下载的模块，下次
go build或go get会重新拉取并校验，首次耗时略长，但确保干净 - 顺手执行
go clean -cache -i，清除构建缓存和go install安装的命令（比如旧版protoc-gen-go）
go get @vX.Y.Z 拉不到预期版本？检查 GOSUMDB 和代理配置
即使环境干净，go get github.com/uber/zap@v1.24.0 仍可能拉到 v1.25.0 或报 checksum mismatch，大概率是 GOSUMDB 或代理干扰了模块解析。
- 确认
go env GOSUMDB是sum.golang.org（截至 2026 年 8 月仍是默认且唯一可信源），不是off或私有地址；恢复默认：go env -w GOSUMDB=sum.golang.org - 检查是否设置了
GO_PROXY：若用的是私有代理（如https://goproxy.cn），确认它支持所请求的 tag；临时绕过代理验证：GO_PROXY=direct go get github.com/xxx/yyy@v1.2.3 - 拉取后立刻验证：运行
go list -m -f '{{.Version}}' github.com/xxx/yyy，输出必须严格等于你指定的@v1.2.3
go mod download -x 能看到真实拉取路径，但别信 vendor 目录
go mod download -x 会打印每一步的 HTTP 请求和解压路径，是排查拉取逻辑最直接的方式。但要注意：如果你项目启用了 vendor，go build 默认从 vendor/ 读依赖，而不是刚拉的新版本——这会导致“明明拉了 v1.2.3，编译却用 v1.2.0”的假象。
- 临时禁用 vendor 验证拉取结果：加
-mod=readonly或-mod=mod参数，例如go build -mod=mod - 彻底更新 vendor：先
go mod tidy同步go.mod，再go mod vendor覆盖整个vendor/目录 - 别在 CI 或多人协作中长期依赖 vendor；它只适合离线构建，不是版本控制的替代品
go get，而是先让 Go 环境本身没机会偷偷加载旧东西——GOROOT 错位、mod 缓存残留、GOSUMDB 关闭、vendor 干扰，任何一个没处理，@v1.2.3 就只是个幻觉。
