答案是PATH中存在多个go可执行文件或GOROOT指向旧路径。需运行which go和go env GOROOT确认实际调用路径与Go自认安装位置，检查shell配置中是否残留旧GOROOT或重复PATH，Apple Silicon用户尤需注意Homebrew与手动安装路径冲突。
go version 显示旧版本？先查 PATH 和 GOROOT 冲突
执行 go version 却看到不是你刚装的版本，大概率是 PATH 中存在多个 go 可执行文件，或者 GOROOT 指向了旧安装路径。Apple Silicon 用户尤其容易遇到 Homebrew 安装的 /opt/homebrew/opt/go@1.26/bin/go 和手动安装的 /usr/local/go/bin/go 同时存在的情况。
- 运行
which go看实际调用的是哪个二进制 - 运行
go env GOROOT确认 Go 认为自己装在哪——它不一定等于你预期的路径 - 检查 shell 配置文件（
~/.zshrc、~/.bash_profile）里是否残留了旧的export GOROOT=...或重复的PATH添加语句 - Homebrew 安装后不要手动再设
GOROOT，它会自动指向/opt/homebrew/opt/go@1.26（Apple Silicon）或/usr/local/opt/go@1.26（Intel）
升级 go@1.26 时 brew upgrade 不生效？删符号链接再重装
Homebrew 的 brew upgrade go@1.26 常因版本锁死或符号链接残留失败。它不会自动覆盖已存在的 /opt/homebrew/bin/go 符号链接，而该链接可能仍指向旧版。
- 先运行
brew unlink go@1.26 - 再运行
brew install go@1.26（不是upgrade） - 验证：
ls -l /opt/homebrew/bin/go应指向../opt/go@1.26/bin/go，且go version输出含go1.26.4 - 若仍卡在旧版，临时移除
/opt/homebrew/bin/go，再重装
macOS Sonoma 上 GOPROXY 必须设，否则 go get 直接超时
从 Go 1.13 起模块代理默认启用，但 macOS Sonoma 下直连 proxy.golang.org 几乎必失败。不设 GOPROXY 会导致 go mod download 卡住、go get 报错 Get "https://proxy.golang.org/...": dial tcp: i/o timeout。
- 设为国内镜像最稳妥：
go env -w GOPROXY=https://goproxy.cn,direct - 避免用多个逗号分隔的代理链（如
https://goproxy.cn,https://goproxy.io,direct），Go 会按顺序尝试，第二个失败就阻塞 - 如果项目依赖私有模块，
direct必须保留，否则无法拉取内网仓库 - 验证是否生效：
go env GOPROXY输出应与设置一致
CGO_ENABLED=0 不是万能钥匙，交叉编译前得看依赖
想给 Linux 容器静态编译二进制？设 CGO_ENABLED=0 确实能禁用 cgo，但很多常用包（如 net、os/user）在纯 Go 模式下行为受限或直接 panic。比如 net/http 在 CGO_ENABLED=0 下无法做 DNS 解析（除非用 netgo 构建标签）。
立即学习“go语言免费学习笔记（深入）”；
- 优先尝试
CGO_ENABLED=0 GOOS=linux go build -o app .，再本地测试核心功能（如 HTTP 请求、文件读写） - 若失败，改用
CGO_ENABLED=1+ Alpine 容器基础镜像（带 musl libc），而非纯静态 - 真正需要无 libc 依赖时，加构建标签：
go build -tags netgo -ldflags '-extldflags "-static"' -o app . - 注意：macOS 上
CGO_ENABLED=0编出的二进制不能直接跑在 Linux，必须指定GOOS/GOARCH
版本更新最麻烦的从来不是下载新包，而是旧路径残留、代理失效、cgo 误判这三类隐形依赖。每次升级后，务必用 go version、go env GOPROXY、go run main.go（含网络和文件操作）三步快速验真。
