goroot是go安装路径，gopath是项目工作区根目录；go 1.11+默认启用module，有go.mod时忽略gopath/src，无则fallback查找；混淆二者易致构建失败或依赖混乱。
Go 环境是否装对，直接决定 go build 和 go run 能不能正常工作——不是报错就是静默失败，而且错误信息往往不指向真实原因。
GOROOT 和 GOPATH 的分工必须清晰
GOROOT 是 Go 安装路径，由安装包自动设置或手动指定；GOPATH 是你放项目的根目录（Go 1.11+ 后非强制，但 go build 在 module 外仍会 fallback 到 GOPATH/src 下找包）。混淆两者会导致：
-
go build找不到fmt等标准库：GOROOT 没设对，go env GOROOT输出为空或错误路径 - 自定义包 import 报 “cannot find package”：项目没在 GOPATH/src/xxx 下，且又没启用 module
-
go install生成的二进制跑到 $GOBIN 失效：GOBIN 未加入 PATH，或 GOPATH/bin 不在 PATH 中
验证方式：go env GOROOT 应输出真实安装路径（如 /usr/local/go）；go env GOPATH 应是你期望的工作区（如 $HOME/go），且该路径下存在 src 目录（即使不用它，也别删空）。
go build 在 module 模式和 GOPATH 模式下行为完全不同
Go 1.11+ 默认启用 module，但是否进入 module 模式，取决于当前目录下有没有 go.mod 文件。这个开关直接影响 go build 查找依赖的方式：
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 有
go.mod：只认当前模块及replace/require声明的依赖，完全忽略 GOPATH/src - 无
go.mod：回退到 GOPATH 模式，go build main.go会尝试从$GOPATH/src加载所有 import 的包 - 混用风险：在 GOPATH/src/myproj 下执行
go mod init后，若忘记go mod tidy，go build可能漏掉间接依赖，运行时报undefined: xxx
建议：新项目一律先 go mod init example.com/myapp，再写代码；老项目迁移时，用 go list -f '{{.Dir}}' . 确认当前路径是否被 GOPATH/src 包含，避免意外 fallback。
go run 和 go build 对 main 包的处理逻辑差异易被忽略
go run 表面方便，实则隐藏了构建上下文判断。它和 go build 在以下场景表现不一致：
-
go run .会自动发现当前目录下所有.go文件并编译，包括测试文件（如main_test.go），而go build .默认跳过 _test.go - 多个
main函数共存时：go run main.go helper.go成功，但go build main.go helper.go也成功；而go run .会报错 “multiple main packages”，因为扫描到多个含func main()的文件 -
go run不生成中间产物，所以无法用ldflags注入版本信息；go build -ldflags="-X main.version=1.2.3"才行
调试建议：当 go run 成功但 go build 失败时，先执行 go list -f '{{.Name}}' . 看是否识别出 main 包；再用 go build -x 查看实际调用的编译命令链，常能暴露路径或参数问题。
最常被绕过的点是：module 初始化后没清理残留的 GOPATH/src 同名路径，导致 go build 一半走 module、一半 fallback，依赖版本混乱。动手前，先确认 go env GOPATH 和当前项目路径的关系，比反复重装 Go 更有效。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
