根本原因是PATH未正确配置或Shell配置未生效；需确认GOROOT/GOPATH路径并添加到PATH，source配置文件（Linux/macOS）或修改系统环境变量（Windows），再验证go version是否成功。
Go安装后go version报“command not found”
根本原因通常是GOPATH或GOROOT没加进系统PATH，或者Shell配置未生效。macOS和Linux用户容易漏掉source ~/.zshrc（或~/.bashrc），Windows用户则常把路径粘贴错位置——比如填进了用户变量却忘了重启终端，或填在系统变量里但没用双引号包裹含空格的路径（如C:\Program Files\Go\bin）。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 确认
go二进制实际位置：ls -l /usr/local/go/bin/go（macOS/Linux）或检查安装向导默认路径（Windows通常为C:\Go\bin） - Linux/macOS：在
~/.zshrc末尾追加export PATH=$PATH:/usr/local/go/bin，然后运行source ~/.zshrc - Windows：在“系统属性 → 高级 → 环境变量”中，编辑
PATH，新增一行C:\Go\bin（不要带引号，也不要用Program Files路径） - 验证：新开一个终端，直接运行
go version，不报错才算成功
go mod init失败提示“cannot determine module path”
这是Go 1.13+启用模块模式后的典型问题，本质是当前目录不在$GOPATH/src下，且未显式指定模块名。Go试图从目录路径推断模块名（比如/home/user/myproject会被猜成myproject），但若目录名含大写字母、短横线或以数字开头，就会拒绝。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 运行
go mod init时必须带参数，例如go mod init example.com/hello，推荐用类域名格式，哪怕只是本地开发 - 避免用
go mod init hello-world或go mod init 123api，这些会直接报错 - 如果已在错误目录下执行过
go mod init并生成了go.mod，删掉它再重试，否则Go会沿用旧模块名继续报错 - 不需要非得把项目放在
$GOPATH里——模块模式下，任意路径都合法，只要go.mod存在且模块名合规
Windows上go get卡住或超时
国内用户最常见现象是go get -u golang.org/x/tools卡在“Fetching”或直接返回timeout。这不是Go本身问题，而是golang.org域名被阻断，且Go默认不走代理（即使系统设置了HTTP_PROXY）。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 优先使用国内镜像：执行
go env -w GOPROXY=https://goproxy.cn,direct（注意direct不能省，否则私有模块无法拉取） - 临时禁用校验（仅调试用）：
go env -w GOSUMDB=off，但上线前务必关掉，否则有依赖劫持风险 - 不用手动改
http_proxy环境变量——Go 1.13+对代理支持不稳定，镜像方式更可靠 - 验证是否生效：运行
go env GOPROXY，输出应为https://goproxy.cn,direct
go run报“no Go files in current directory”但明明有.go文件
常见于文件名拼写错误或隐藏字符干扰。Go要求入口文件必须是package main且含func main()，但更隐蔽的问题是文件名带空格、中文、或后缀不是.go（比如main.go.txt在Windows下可能被隐藏扩展名）。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
ls -la（macOS/Linux）或dir /a（Windows）确认真实文件名，特别注意是否多出.txt或空格 - 检查首行是否为
package main（不能是package Main或package foo） - 确认没有
//go:build ignore这类构建约束注释意外屏蔽了文件 - 如果用VS Code，关闭“Files: Auto Save”并手动保存一次，有时编辑器缓存会导致文件未真正落盘
go env输出比重装更有效。尤其是GOROOT和GOPATH的值，很多人改了配置却没意识到go env显示的是当前生效值，不是配置文件里的字符串。 
