GOROOT必须指向Go安装根目录（如/usr/local/go），GOPATH应设为单一工作区路径（如$HOME/go），二者不可重叠；PATH需同时包含$GOROOT/bin和$GOPATH/bin；go run报找不到包时，优先验证go env GOROOT GOPATH输出是否为正确绝对路径，并确保项目用go mod init初始化而非依赖GOPATH模式。
GOROOT 和 GOPATH 配置错，go run 就会报找不到包
Go 1.16 之后默认启用 go modules，但很多老项目、教程仍依赖 GOPATH 模式。如果你在非 $GOPATH/src 目录下执行 go run main.go 却提示 cannot find package，大概率是环境变量没配对或路径不规范。
-
GOROOT必须指向 Go 安装根目录（如/usr/local/go），不能指向bin子目录 -
GOPATH推荐只设一个路径（如$HOME/go），且不要和GOROOT重叠 -
PATH中必须同时包含$GOROOT/bin和$GOPATH/bin，否则go install的二进制找不到 - 验证方式：运行
go env GOROOT GOPATH，输出应为绝对路径，无空格或中文
用 go mod init 初始化项目比手动建 GOPATH 更可靠
现在新项目几乎不需要碰 GOPATH。直接在项目根目录运行 go mod init example.com/myapp，就能生成 go.mod 文件并启用模块模式——这意味着你可以把项目放在任意路径，import 语句也不再受目录结构限制。
- 模块名不必真实可访问，只是命名空间标识（如
myproject也合法） - 后续加依赖时，
go get github.com/gin-gonic/gin会自动写入go.mod并下载到go/pkg/mod - 如果已有
vendor目录，先删掉再go mod tidy，避免混合管理模式出错
go build 和 go run 行为差异直接影响调试效率
go run 是边编译边执行，适合快速验证逻辑；go build 生成可执行文件，能暴露链接期问题（比如 cgo 依赖缺失）。很多人卡在 “本地 go run 成功，但 go build 失败”，本质是忽略了构建上下文差异。
-
go run默认忽略//go:build约束，而go build严格检查（尤其跨平台编译时） - 若用
cgo，CGO_ENABLED=0 go build会直接失败，但go run可能侥幸通过 - 交叉编译（如
GOOS=linux go build）必须用go build，go run不支持
别跳过 go fmt 和 go vet ——它们不是“锦上添花”
这两条命令不是格式化工具或静态检查的可选项，而是 Go 工程实践的底线。很多隐蔽 bug（比如未使用的变量、错误的循环变量捕获）在 go vet 下立刻暴露，而 go fmt 统一缩进和括号风格后，git diff 才真正反映逻辑变更。
立即学习“go语言免费学习笔记（深入）”；
-
go fmt ./...会递归格式化所有子包，不是只改当前文件 -
go vet ./...检查范围比go build更广，例如发现fmt.Printf参数类型不匹配 - CI 中建议把
go vet当作编译前必过环节，否则容易在线上触发 panic
go mod 初始化后没删掉旧的 vendor 目录——这两个点看似简单，却让大量初学者反复卡在“明明按教程做了，就是跑不通”。 
