go命令调用的是path中优先匹配的版本，根源在于which go与go version不一致：若which go返回/usr/bin/go而go version显示go1.12或更早，说明系统包管理器安装的旧版go被优先调用，导致gopath等环境变量失效。
go命令调用的是哪个版本？先查清楚
路径冲突的根源永远是 which go 和 go version 对不上——你设了新版 GOPATH，但实际跑的是系统自带的老版 go。典型表现是 go env GOPATH 为空或返回 /usr/lib/go 这类只读路径，而 echo $GOPATH 明明输出了你的个人目录。
必须按顺序验证：
-
which go—— 看它指向哪，/usr/bin/go就是危险信号 -
go version—— 如果是go1.12或更早，基本可以断定是 Ubuntu/Debian 包管理器装的旧版 -
go env GOROOT—— 如果和which go的父目录不一致（比如which go返回/usr/bin/go，但GOROOT是/usr/local/go），说明环境变量和二进制完全错位
PATH顺序错了，新版go根本没被用上
Linux/macOS 查找命令靠 PATH 从左到右扫描，只要旧版 go 路径排在前面，新版就永远被绕过。常见错误配置：
- 在
~/.zshrc里写了export PATH="$PATH:/usr/local/go/bin"——$PATH在前，旧版优先 - Homebrew 安装的
go（路径如/opt/homebrew/bin/go）没卸载，且其路径在 PATH 中比goenv的 shims 更靠前 - 手动解压新版 Go 后，忘了把
/usr/local/go/bin加进 PATH，或者加了但位置不对
正确做法只有一条：新版 bin 目录必须放在 PATH 最左边：
export PATH="/usr/local/go/bin:$PATH"
写进 ~/.zshrc 或 ~/.bash_profile，然后 source 生效。验证：重启终端后 which go 必须输出 /usr/local/go/bin/go。
GOBIN没设，go install往GOROOT里硬写
当 GOBIN 为空，且 GOPATH 也没设时，go install 会退回到 $GOROOT/bin —— 而这个目录通常只有 root 有写权限，报 permission denied 就是它干的。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
别依赖默认行为，显式控制输出位置：
- 设
GOBIN=$HOME/go/bin（推荐，和 GOPATH 分开，避免 bin 目录混入 src/pkg） - 确保
$GOBIN目录存在：mkdir -p $GOBIN - 把
$GOBIN加进 PATH：export PATH="$GOBIN:$PATH"，否则装完的命令找不到 - 检查
go env GOBIN输出是否是你设的路径，不是空字符串
注意：GOBIN 和 GOPATH 是独立的。即使你用 Modules，go install 依然走 GOBIN；没设 GOBIN 才 fallback 到 $GOPATH/bin。
多个Go管理工具打架：goenv、brew、手动安装共存
goenv 通过 ~/.goenv/shims 拦截命令，但它的 shims 只有在 PATH 最前才生效。如果 brew 装的 go 或手动解压的 /usr/local/go/bin/go 排在前面，goenv 就形同虚设。
最干净的解法是只留一种管理方式：
- 用 goenv 就彻底卸载 brew 的：
brew uninstall go，删掉/usr/local/go - 用官方二进制就删掉 goenv：
rm -rf ~/.goenv，清掉所有goenv相关的 PATH 行 - 检查
which go输出路径是否存在残留软链接：ls -la /usr/local/bin/go，有就sudo rm -f /usr/local/bin/go
多工具共存不是不行，但要求你对 PATH 顺序有绝对掌控力——多数人掉坑里，都是因为以为“装了 goenv 就万事大吉”，结果 PATH 里还躺着三个其他 go。
路径冲突的本质不是配置多，而是执行链断裂：你改的环境变量，没被真正运行的那个 go 二进制读到。每一步都要用 which、go version、go env 交叉验证，而不是只信自己写的 export 行。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
