根本原因是PATH中旧版Go路径优先级更高；需将新版go/bin置于PATH最前并source配置，GOROOT通常无需手动设置，GO111MODULE=on必须启用。
Go 1.21+ 安装后 go version 报错或显示旧版本？
常见现象是执行 go version 仍输出 go1.19.12，哪怕刚装完 go1.22.3。根本原因通常是系统 PATH 中存在旧版 Go 的 bin 目录（比如 /usr/local/go/bin 或用户家目录下的旧解压路径），且排在新安装路径前面。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 运行
which go查看当前生效的go二进制位置 - 用
echo $PATH检查路径顺序，把新版 Go 的bin目录（如$HOME/sdk/go/bin）提前到最左 - 修改 shell 配置文件（
~/.zshrc或~/.bashrc），确保export PATH="$HOME/sdk/go/bin:$PATH"在其他 Go 相关 PATH 设置之前 - 重启终端或执行
source ~/.zshrc后再验证
为什么 GOROOT 通常不该手动设置？
Go 自 1.16 起默认自动推导 GOROOT：只要 go 命令本身在标准安装路径下（如 /usr/local/go 或 $HOME/sdk/go），它就能正确识别自己的根目录。手动设 GOROOT 不仅多余，还容易引发 cannot find package "fmt" 这类基础包报错——尤其是当你用不同方式（brew / pkg / tar.gz）混装多个 Go 版本时。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 检查是否在 shell 配置中写了
export GOROOT=...，删掉它 - 运行
go env GOROOT确认输出是否为实际安装路径；若为空或错误，说明没被干扰 - 只有在极少数场景（如自定义编译 Go 工具链、嵌入式交叉构建）才需显式设
GOROOT
GO111MODULE=on 是必须打开的吗？
是的，除非你还在维护 Go 1.10 之前的遗留项目。从 Go 1.16 开始，默认开启模块模式（GO111MODULE=on），关闭它会导致 go get 无法解析现代依赖、go mod 命令失效、甚至 go build 找不到本地 replace 的模块。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 不要依赖临时设置，直接写入环境变量：
export GO111MODULE=on到 shell 配置文件 - 验证：新建空目录，运行
go mod init example.com/test，成功生成go.mod即表示生效 - 注意：某些 CI 环境或旧 Docker 镜像可能默认关着，部署前务必检查
go env GO111MODULE
VS Code + Go 插件启动慢、gopls 高 CPU？
这不是插件问题，而是 gopls（Go language server）在首次索引整个 GOPATH 或模块依赖树时的行为。尤其当项目含大量 vendor、或 go.work 包含数十个子模块时，初始化延迟可达 2–5 分钟，CPU 占用飙高。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 确认工作区根目录下有
go.mod，避免gopls误判为 GOPATH 模式全盘扫描 - 在 VS Code 设置里加配置：
"go.toolsEnvVars": { "GOWORK": "" }，禁用go.work（除非真需要多模块协同） - 排除无关目录：在
.vscode/settings.json中设置"files.watcherExclude"和"go.goplsEnv"过滤node_modules、vendor等 - 观察
gopls日志（命令面板 → “Go: Toggle gopls log”），重点看Initializing workspace阶段卡在哪
真正麻烦的不是装不装得上，而是哪些路径和变量会悄悄覆盖你的预期——尤其是 PATH 顺序、shell 配置加载时机、以及 gopls 对工作区结构的隐式假设。
