常见现象是go version正常但go build报“object is [X] expected [Y]”，或which go与go env GOROOT路径不一致；本质是PATH混入旧版go二进制而GOROOT指向另一版本标准库，修复需清理PATH中所有go相关路径，再精确注入当前GOROOT/bin并确保GOPATH/bin也在PATH中。
GOROOT 和 PATH 不匹配导致 go 命令找不到或报错
常见现象是 go version 正常，但 go build 报错“object is [X] expected [Y]”，或者 which go 返回路径和 go env GOROOT 指向不同目录。本质是 PATH 里混入了旧版 go 可执行文件，而 GOROOT 指向另一个版本的标准库。
修复脚本必须先清理 PATH 中所有疑似 Go 的 bin 路径，再精确注入当前 GOROOT 的 bin 目录：
- 用
echo $PATH | tr ':' '\n' | grep -i 'go\|golang'找出所有可疑路径 - 在脚本中用
export PATH=$(echo $PATH | tr ':' '\n' | grep -v -i 'go\|golang' | tr '\n' ':' | sed 's/:$//')清空干扰项 - 显式设置
export GOROOT=/usr/local/go（按实际路径改），再追加export PATH=$GOROOT/bin:$PATH - Windows 脚本需用
set PATH=%PATH:;C:\Go\bin=;%类似逻辑清理，再set PATH=C:\Go\bin;%PATH%
GO111MODULE=auto 导致老项目意外进入 GOPATH 模式
很多脚本只设 GO111MODULE=on，但没考虑项目根目录下没有 go.mod 时，auto 仍会退回到 GOPATH 模式——尤其当 GOPATH 被设为非默认值时，go get 会把包下到错误位置。
脚本里应强制关闭歧义：
立即学习“go语言免费学习笔记（深入）”；
-
export GO111MODULE=on是底线，不能省略 - 若需兼容无
go.mod的旧项目，改用export GO111MODULE=off并确保GOPATH已正确定义 - 避免用
auto—— 它依赖当前目录是否有go.mod，而脚本执行时工作目录不可控 - 验证：运行
go env GO111MODULE，输出必须是on或off，绝不能是auto
GOPATH/bin 未加入 PATH 导致 go install 工具不可用
go install golang.org/x/tools/gopls@latest 成功后，gopls 命令却提示 “command not found”，90% 是因为脚本漏了把 $GOPATH/bin 加进 PATH。
注意三点：
-
GOPATH默认是$HOME/go，但脚本里如果自定义了（比如export GOPATH=~/mygo），必须同步更新PATH中的对应路径 - 顺序很重要：
export PATH=$GOROOT/bin:$GOPATH/bin:$PATH，把$GOPATH/bin放在$GOROOT/bin后面，避免覆盖go命令本身 - macOS/Linux 脚本里别写
$GOPATH/bin而不展开——export PATH="$GOPATH/bin:$PATH"必须用双引号，否则变量不生效
脚本 source 后 IDE 不继承环境变量
VS Code 或 GoLand 从桌面图标启动时，根本不读 ~/.zshrc 或 ~/.bash_profile，所以即使脚本执行成功，IDE 内置终端还是看不到 GOROOT。
这不是脚本问题，是启动方式问题：
- macOS：必须从终端运行
code .，而不是点击图标 - Linux：同理，用
env $(cat ~/.zshrc | grep export | sed 's/export //') code .临时注入（更稳妥） - Windows：用 PowerShell 运行
start "" "C:\Users\me\AppData\Local\Programs\Microsoft VS Code\Code.exe"，它会继承当前会话环境 - 终极方案：在 VS Code 的
.vscode/settings.json里硬编码"go.goroot": "/usr/local/go"，绕过 shell 环境依赖
