golang版本切换的实现

先说几个核心判断：在 CentOS 下给 Go 项目做版本升级，确实可能踩到不少坑，尤其是当你习惯把所有环境变量集中管理时。今天就把我踩过的坑和解决思路拆开说说，希望对你有帮助。

事情是这样的：某个项目需要把 Go 从 1.20.x 升级到 1.21.x。我的习惯是把 GOROOT、GOPATH、GOMODCACHE 全部放在同一个大目录 A 下——1.20 版本就安安稳稳躺在那里。我没有直接删除旧版本，而是在 ~/.bashrc（CentOS）里写了类似这样的配置：

export GOROOT=/A/goroot
export GOBIN=$GOROOT/bin
export PATH=$PATH:$GOBIN

同时，go env 里的 GOMODCACHE 指向 /A/cache_dir，所有第三方依赖都缓存到这里。

升级也挺直接：下载 1.21.13 版本，把对应的文件解压到另一个目录 B 下（/B/goroot）。然后修改 ~/.bashrc，把 GOROOT 指向新路径：

export GOROOT=/B/goroot
export GOBIN=$GOROOT/bin
export PATH=$PATH:$GOBIN

看起来一切顺利？结果 go mod tidy 直接甩了个错误：

compile: version "go1.20.14" does not match go tool version "go1.21.13"

版本不匹配？这不科学。我尝试跑 go mod edit -go=1.21.13 来强制修改 go.mod 中的 Go 版本，结果又冒出新错误：

github.com/prometheus/client_golang/prometheus imports
        google.golang.org/protobuf/types/known/timestamppb tested by
        google.golang.org/protobuf/types/known/timestamppb.test imports
        github.com/google/go-cmp/cmp/cmpopts: github.com/google/go-cmp@v0.5.7: verifying go.mod: missing GOSUMDB

问题出在哪儿？原来 go mod tidy 干的事情不止是“整理依赖”那么简单。它会：

- 扫描项目中的所有 .go 文件
- 解析 import 语句
- **检查代码语法**（需要知道 Go 版本）
- 根据 go.mod 中的 Go 版本决定支持哪些语言特性
- 添加缺失的依赖，移除不需要的依赖

关键点是第三行——它要按新版 Go 的语法检查所有文件，但缓存里那些旧版本编译过的依赖，其 go.sum 记录的是旧版的环境，新旧版本一碰撞，校验就炸了。

最直接的解决办法：把旧版缓存清掉，重新下一遍——但我不打算这么做。项目之后可能还会切回旧版，留着缓存更省事。于是我在 B 目录下新建一个 cache_dir，然后用 go env -w GOMODCACHE="/B/cache_dir" 把缓存路径切换到新的空目录。再执行 go mod tidy，问题解决。

这里还得提一个容易忽略的坑：如果你用 VSCode 编辑器，它的终端环境变量不一定和系统 ~/.bashrc 同步。我当初在 workspace settings 里写了这样一段配置：

{
    "go.goroot": "/A/go",
    "go.alternateTools": {},
    "go.toolsManagement.go": "/A/go/bin/go"
}

所以即便我更新了 ~/.bashrc，在 VSCode 内部开启的终端里，调用的仍然是旧版 Go 1.20。这个也要记得一起改，不然你会纳闷为什么终端里的 go version 明明是新版，一跑 go mod tidy 又报错。

说实话，这趟升级体验谈不上愉快。只改 GOMODCACHE 虽然能绕过问题，但我总感觉 Go 的设计团队不应该让版本切换这么折腾人。后来调研发现，人家其实早就提供了更优雅的方案——gvm（Go Version Manager）。关于怎么用 gvm 来彻底解决多版本共存的问题，我们下一篇再细聊。