go version报错或“command not found”根本原因是PATH未包含$GOROOT/bin；需确认go二进制存在，再将对应bin路径加入PATH并source配置文件，Windows还需确保GOROOT已定义。
go version 命令输出异常或报“command not found”
说明 go 二进制未被 shell 正确识别，根本原因几乎全是 PATH 未包含 $GOROOT/bin（或安装路径下的 bin）。不是“没装好”，而是“找不到”。
- Linux/macOS：检查
echo $PATH是否含/usr/local/go/bin（默认安装路径）或你自定义的安装路径；若无，追加export PATH=$PATH:/usr/local/go/bin到~/.zshrc或~/.bashrc，再执行source ~/.zshrc - Windows：确认系统环境变量
PATH中是否添加了%GOROOT%\bin（如C:\Go\bin），且GOROOT自身已正确定义（非必须但推荐显式设置） - 别用
which go判断——它依赖PATH；应先用ls -l /usr/local/go/bin/go（macOS/Linux）或dir C:\Go\bin\go.exe（Windows）确认文件真实存在
多个 Go 版本共存时如何安全切换
硬编码修改 GOROOT 或反复重装是反模式。现代长期维护场景下，必须用版本管理工具隔离运行时。
- 推荐
gvm（soulteary/gvm）或asdf：gvm install go1.21.6+gvm use go1.21.6可瞬时切换，且每个版本独立编译、独立GOPATH缓存 - 避免使用系统包管理器（如
apt install golang-go）安装主版本——它们常滞后、难卸载、与手动安装冲突 - 验证切换效果：执行
go version和which go，二者输出路径应一致且指向当前激活版本的bin目录 - 项目级锁定：在
go.mod文件首行写明go 1.21，CI/CD 流程中用gvm use $(cat go.mod | head -n1 | cut -d' ' -f2)自动匹配
GO111MODULE=on 是默认值，但老项目仍可能失败
Go 1.16+ 默认启用模块模式，但若项目根目录无 go.mod 或存在 vendor/ 且 GO111MODULE 被意外设为 auto，go build 会退化为 GOPATH 模式，导致依赖解析错乱。
- 强制启用：在 shell 配置中加
export GO111MODULE=on（不建议关或 auto） - 检查当前状态：
go env GO111MODULE输出必须是on - 旧项目迁移：在项目根目录运行
go mod init example.com/project，再go mod tidy生成干净依赖树；删除vendor/（除非 CI 明确要求离线构建） - 注意
CGO_ENABLED=0等交叉编译变量不影响模块行为，但会改变构建产物兼容性
为什么不用 GOPATH，但还得保留 $HOME/go 目录
GOROOT 是 Go 安装位置，GOPATH 是旧版工作区概念——模块模式下它不再控制依赖查找，但仍是 go get 下载源码、go install 安装命令的默认落点。
立即学习“go语言免费学习笔记（深入）”；
- 不设
GOPATH会导致go install报错或把二进制写入$HOME/go/bin（隐式 fallback），而该路径未必在PATH中 - 建议显式设置：
export GOPATH=$HOME/go，并确保$GOPATH/bin在PATH中（与$GOROOT/bin并列） -
$HOME/go/src不再用于存放项目源码（项目可放任意路径），但go list -m all的本地缓存、go tool trace生成文件等仍受GOPATH影响 - 企业环境中常将
GOPATH设为只读 NFS 挂载点，避免开发者误改缓存——此时需提前配置GOENV指向本地.goenv
GOROOT、GOPATH、GO111MODULE 等关键配置写进 .tool-versions（asdf）或 go.env（gvm），而不是只靠人肉记忆或文档。否则三年后接手的人打开终端第一件事，就是花两小时还原你当年的 export 顺序。 
