go version显示旧版本但实际用新版本，通常因goroot未指向新安装路径或shell缓存旧路径；which go与echo $goroot不一致即表明环境变量未生效或被覆盖，常见于配置文件中path重复定义、ide未加载shell配置、windows多版本残留等。
go version 显示旧版本但实际用的是新版本
这种情况通常是因为 $GOROOT 没指向你刚安装的旧版本，或者 shell 缓存了旧的 go 路径。执行 which go 和 echo $GOROOT 对照看：如果两者不一致，说明环境变量没生效或被覆盖。
常见干扰源：
-
~/.bashrc或~/.zshrc里有多个export PATH=...，后写的覆盖了前边的； - 某些 IDE（如 VS Code）启动时没加载 shell 配置，得手动在终端里
source ~/.zshrc再启动； - Windows 上同时装了 MSI 版和 ZIP 版 Go，注册表或 PATH 里残留旧路径。
用 gvm 切换版本后 go build 报错 “go: cannot use go X.Y.Z with go X.Y+ mod”
这是 Go 模块声明版本（go 行）与当前 Go 运行版本不兼容的硬性报错。比如 go.mod 里写着 go 1.22，但你用 gvm use go1.21.6，就会触发。
解决方法只有两个方向：
- 降级
go.mod的声明：运行go mod edit -go=1.21，再go mod tidy； - 升级项目适配：改代码兼容新语法（如泛型、
io.ReadAll替代io/ioutil.ReadAll），再保留go 1.22； - 别混用——如果项目明确要求
go 1.22，就别强行切到go1.21，否则后续依赖可能拉不到正确版本。
手动解压多个 Go 版本时软链接容易出错
直接用 ln -s 指向不同版本的 go 目录，看似简单，但极易踩坑：
- 软链接目标路径写相对路径（如
ln -s ../go1.21.6 go），切换目录后失效； - 没清掉旧的
~/.go/pkg缓存，导致go build仍用旧版本缓存的包； - 没重命名原始
/usr/local/go，新软链接被系统自带 Go 覆盖。
安全做法是：所有版本解压到独立绝对路径（如 /opt/go/go1.21.6），软链接始终用绝对路径创建，并在每次切换后运行 go clean -modcache。
go get @v0.x 降级后编译失败，但错误不提示版本问题
Go 不会在错误信息里直接说“你用了 v0.4.0，但它删了 DoSomething()”，而是报 undefined: DoSomething 或 cannot use ... as type ...。这时候得反查：
- 进该模块 GitHub 的
v0.4.0tag，看doc.go或CHANGELOG.md是否写了 breaking change； - 用
go doc github.com/xxx/yyy@v0.4.0 PackageName.FuncName确认函数是否存在； - 对比
go list -f '{{.Imports}}' github.com/xxx/yyy@v0.4.0和@v0.5.0，看导入路径是否变了（比如从xxx/v2改成xxx）。
真正麻烦的是 v0.x 版本——语义化版本规则对 v0.x 不强制，作者随时删 API，所以回退前务必查 commit log，不能只信 tag 名。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
