go version 命令报错说明 Go 二进制未加入 PATH，最常见于手动解压安装后未配置环境变量；Linux/macOS 需确认 ~/.zshrc 或 ~/.bashrc 中含 export PATH=$PATH:/usr/local/go/bin 并 source 生效，Windows 需检查系统 PATH 是否含 %GOROOT%\bin 且 GOROOT 已正确定义。
go version 命令报错或不识别
说明 Go 二进制文件没进 PATH，最常见于 Linux/macOS 手动解压安装后忘记配置环境变量，或 Windows 安装时勾选了“Add to PATH”但实际未生效。
检查方式：运行 which go（macOS/Linux）或 where go（Windows），无输出即未注册。
- Linux/macOS：确认
~/.zshrc或~/.bashrc中包含export PATH=$PATH:/usr/local/go/bin（路径需与实际GOROOT一致），然后执行source ~/.zshrc - Windows：在系统环境变量中检查
PATH是否含%GOROOT%\bin，且GOROOT已正确定义为C:\Go或自定义路径 - 验证：新开终端，直接运行
go version，应输出类似go version go1.23.1 darwin/arm64
go mod init 后依赖下载失败或超时
本质是模块代理不可达，默认 https://proxy.golang.org 在国内基本不可用，不是网络问题，而是策略性屏蔽。
临时绕过：加 -insecure 参数（不推荐）；长期方案必须设 GOPROXY。
立即学习“go语言免费学习笔记（深入）”；
- 推荐命令（永久生效）：
go env -w GOPROXY=https://goproxy.cn,direct - 验证是否生效：
go env GOPROXY应返回设置值 - 若仍失败，检查是否被公司代理拦截——可尝试加
no_proxy=.goproxy.cn环境变量 - 注意：
direct表示对私有域名（如内部 Git）直连，避免代理转发失败
go run 和 go build 行为不一致
常见于项目根目录外执行命令，或 go.mod 位置错误。Go 不按当前路径找 go.mod，而是向上逐级查找最近的 go.mod 文件。
典型现象：在子目录下 go run main.go 报错 no required module provides package。
- 确认当前工作目录是否含
go.mod；若没有，先cd到项目根目录再操作 -
go run默认只编译并运行指定文件，不检查模块完整性；go build则严格校验依赖，因此后者更容易暴露go.sum校验失败或缺失require - 修复依赖：运行
go mod tidy，它会自动补全缺失依赖、清理未使用项，并更新go.sum
GOPATH 还需要手动设置吗
Go 1.13+ 默认启用模块模式（GO111MODULE=on），GOPATH 对依赖管理已无作用——不再从 $GOPATH/src 查包，也不强制要求项目放在此路径下。
但仍有两个残留用途：
-
$GOPATH/bin仍是go install默认输出可执行文件的位置，建议保留并加入PATH - 部分老工具（如某些
go get安装的 CLI 工具）仍默认写入$GOPATH/bin，不设会导致命令找不到 - 无需再设
GOPATH为项目根目录；现代项目可放在任意路径，只要含go.mod
真正容易被忽略的是：即使不用 GOPATH 管理源码，go install 生成的二进制仍默认落进 $GOPATH/bin，而很多人忘了把它加进 PATH，结果装完命令却用不了。
