根本原因是Windows安装MSI包后PATH未被当前终端继承，必须关闭所有终端再新开；若仍失败，需确认%GOROOT%\bin（如C:\Program Files\Go\bin）已手动添加至系统PATH。
go install 后为什么 go version 还报“不是内部或外部命令”
根本原因是 Windows 安装 .msi 包后，环境变量没被当前 CMD/PowerShell 会话继承。哪怕安装时勾选了“添加到 PATH”，也必须关掉所有终端窗口再新开——这是最常被跳过的一步。
验证方法：打开全新 PowerShell，直接执行 go version。如果仍失败，说明 %GOROOT%\bin 没进系统 PATH（比如装到了 D:\software\Go，那就要确认 D:\software\Go\bin 是否在环境变量里）。
- 别在已打开的终端里反复
refreshenv或source，无效 - 别手动改 PATH 时漏掉
\bin后缀（常见错写成D:\software\Go而非D:\software\Go\bin） - 如果用的是旧版 Windows（如 Win7），检查是否启用了“用户账户控制 UAC”导致 PATH 写入受限
不设 GOPATH 也能跑项目？是的，但得满足三个条件
Go 1.16+ 默认启用模块模式（GO111MODULE=on），GOPATH 已非必需。但不设它，不代表随便建个文件夹就能 go run 成功。
真正起作用的是：go.mod 文件是否存在、模块路径是否合法、当前目录是否在模块根下。
立即学习“go语言免费学习笔记（深入）”；
- 新建项目必须先执行
go mod init example.com/hello（模块名不能是纯字母，建议带域名或 GitHub 用户名） - 如果
main.go在子目录里，go run必须指定路径，如go run ./cmd/server，不能只写go run main.go - 模块名若写成
hello（无域名），后续go get引入第三方包可能触发replace或校验失败
go run 和 go build 的编译行为差异直接影响调试体验
go run 是临时编译 + 立即执行 + 自动清理二进制；go build 是生成持久可执行文件。但很多人没意识到：它们默认使用的编译器参数不同，尤其影响 CGO 和符号表。
-
go run默认禁用-ldflags="-s -w"，所以能用 delve 断点调试；go build默认保留全部调试信息，体积略大 - 如果
go run报undefined: C.xxx，大概率是源码里用了// #include <xxx.h>但没开 CGO，需加CGO_ENABLED=1前缀 -
go build -o app.exe生成的文件可直接双击运行；go run输出的临时文件路径藏在%TEMP%\go-build*下，无法复用
国内拉包超时不是代理没配好，而是 GOSUMDB 卡住了
配置了 GOPROXY=https://goproxy.cn,direct 却还是 go get 失败？十有八九是 GOSUMDB 校验环节被墙。它默认连 sum.golang.org，这个域名在国内解析慢甚至超时，导致整个依赖下载阻塞。
正确做法不是关掉校验（GOSUMDB=off 有安全风险），而是换国内镜像：
- 执行
go env -w GOSUMDB=sum.golang.google.cn（官方提供的国内校验服务） - 验证：运行
go env | findstr GOSUMDB，输出应为GOSUMDB=sum.golang.google.cn - 若仍失败，可临时加
-insecure参数绕过（仅限内网测试）：go get -insecure github.com/gorilla/mux
模块校验和验证是 Go 生态安全底座，跳过它等于放弃依赖完整性保障——这点容易被忽略，但比代理配置本身更关键。
