根本原因是shell类型与配置文件不匹配：macOS Catalina后默认zsh，但用户误改~/.bashrc（zsh不读取），应根据echo $SHELL结果编辑~/.zshrc或~/.zprofile，并source生效。
为什么 source ~/.zshrc 后 go version 仍报 command not found
根本原因不是配置写错了，而是 shell 类型和配置文件不匹配。macOS Catalina 及之后默认用 zsh，但很多人还在改 ~/.bashrc——这个文件压根不会被 zsh 自动读取。
检查当前 shell：运行 echo $SHELL，输出是 /bin/zsh 就别碰 ~/.bashrc；如果是 /bin/bash，才该改它。
- zsh 用户应编辑
~/.zshrc或~/.zprofile（后者在登录时执行，更稳妥） - bash 用户改
~/.bashrc，但需确认终端是否以 login shell 方式启动（GUI 终端常不是，此时~/.bash_profile才生效） - 改完必须
source ~/.zshrc（或对应文件），不能只靠新开终端——新开终端也可能继承旧环境
echo $PATH 正确却 still can't find go
PATH 看起来有 /usr/local/go/bin，但 which go 返回空，说明路径顺序或拼写有隐性问题。
常见陷阱：
立即学习“go语言免费学习笔记（深入）”；
-
export PATH=$PATH:/usr/local/go/bin写成export PATH=/usr/local/go/bin:$PATH—— 看似一样，但若前面已有冲突路径（比如旧版 Go 的 bin），优先级变了 - 路径末尾多了一个空格：
export PATH="$PATH: /usr/local/go/bin"，导致实际变成:/usr/local/go/bin（开头冒号会被解释为当前目录） - GOROOT 被设错，比如
export GOROOT=/usr/local/Cellar/go/1.22.3/libexec（Homebrew 安装路径），但没同步更新PATH里的 bin 路径
验证方法：运行 ls -l /usr/local/go/bin/go 确认文件存在且有执行权限；再用 /usr/local/go/bin/go version 直接调用，绕过 PATH。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
go env 显示 GOPATH 为空，但明明 export 过了
go env GOPATH 输出空，并不等于环境变量没设——Go 工具链从 Go 1.12 起默认忽略未显式设置的 GOPATH，转而使用 $HOME/go 作为隐式值，除非你手动 export。
但问题常出在：你 export 的是 GOPATH=$HOME/gopath，而 go env 却显示 /home/user/go。这是因为：
- 某些 Go 安装方式（如 Homebrew）会预设
GOPATH到$HOME/go，且优先级高于用户 shell 配置 - VS Code 或其他编辑器启动终端时，可能加载的是系统级 profile（如
/etc/zshenv），覆盖了你的用户配置 -
go env -w GOPATH=...写入了 Go 内部配置，会覆盖环境变量（可运行go env -u GOPATH清除）
真正要查的是：go env GOPATH 和 echo $GOPATH 是否一致。不一致，说明 Go 在读别的地方。
vim-go 或 gopls 提示 “GOPATH is not set” 却不影响 go run
这是工具链兼容性断层。现代 Go（1.16+）默认启用模块模式，go run 完全不依赖 GOPATH；但老版本插件（如 vim-go 的旧版）仍硬检查 GOPATH 环境变量是否存在，哪怕值为空字符串也会报错。
解决方式不是“一定要设 GOPATH”，而是：
- 升级插件：vim-go 改用
gopls后端，VS Code 的 Go 扩展已默认跳过 GOPATH 检查 - 临时绕过：在项目根目录运行
go env -w GOPATH=$HOME/go（仅影响当前项目） - 彻底弃用：确认
GO111MODULE=on且项目含go.mod，就不用管插件的 GOPATH 报警——它只是 legacy warning
最易被忽略的一点：编辑器内嵌终端和外部终端的环境变量可能不同步。重启编辑器本身，比反复 source 配置文件更有效。
