必须先验证go version和go env：前者确认go命令是否在PATH中，后者检查GOROOT和GOPATH是否指向正确路径，避免后续go mod tidy或go install静默失败。
go version 和 go env 为什么必须先验证
装完 Go 不急着写代码，go version 和 go env 是两道硬门槛。前者确认二进制路径是否真进了 PATH，后者检查 GOROOT 和 GOPATH 是否指向预期位置——尤其是 GOPATH，如果它被设成空目录或权限受限路径（比如 /root/go 而当前用户非 root），后续 go mod tidy 或 go install 会静默失败，只报“no such file or directory”这种模糊错误。
-
go version报command not found→ 检查/usr/local/go/bin（Linux/macOS）或C:\Go\bin（Windows）是否在PATH中，且终端已重载配置（source ~/.zshrc或重启 PowerShell） -
go env GOPATH输出不是你设的路径 → Windows 用户注意系统变量和用户变量别混用；Linux/macOS 用户检查 shell 配置文件是否写错（比如把export GOPATH=...写在了注释行后面） -
go env GOROOT显示为空 → 说明GOROOT没设，但现代 Go（1.16+）通常能自动推导；若手动设了却指向错误目录（如/usr/local/go/go多了一层），go build会找不到标准库
go build 和 go run 的行为差异直接影响调试节奏
go run 是开发时的快捷键，go build 才是交付前的必经步骤。两者核心区别不在“是否生成文件”，而在于执行环境和依赖解析时机：
-
go run main.go：编译临时二进制 → 立即执行 → 删除临时文件；它强制使用当前目录下的go.mod，即使你cd到其他目录运行，也只认main.go所在路径的模块配置 -
go build -o myapp ./...：生成持久可执行文件；若省略-o，默认输出名是目录名（如hello），不是main.go；它会递归扫描子目录，但只编译main包及其直接依赖 - 常见坑：
go build main.go utils.go—— 如果utils.go不在main包里（比如包声明是package utils），编译直接失败，提示 “cannot load utils: cannot find module providing package utils”
交叉编译 Android 或 macOS 二进制时 GOOS/GOARCH 必须显式设置
Go 原生支持交叉编译，但默认只构建当前系统平台。想生成 Android 或 macOS 的可执行文件，不能靠换机器，而是靠环境变量驱动：
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- Android ARM64：
GOOS=android GOARCH=arm64 go build -o app-android main.go；注意：这生成的是静态链接二进制，无需目标设备装 Go 运行时，但要求代码不调用 CGO（否则需 NDK 工具链） - macOS ARM64（M系列芯片）：
GOOS=darwin GOARCH=arm64 go build -o app-macos main.go；若目标是 Intel Mac，改GOARCH=amd64 - Windows 64位：
GOOS=windows GOARCH=amd64 go build -o app.exe main.go；生成的.exe在 Windows 上双击即可运行，无额外依赖 - 关键限制：
GOOS=linux时GOARCH可选amd64/arm64/386，但GOOS=windows下不支持arm64（截至 Go 1.22）
go mod init 后 go mod tidy 为什么常卡住
初始化模块后，go mod tidy 本该自动下载依赖并写入 go.mod，但实际常卡在 “Fetching …” 状态。根本原因不是网络差，而是 Go 的模块代理（proxy）策略变化：
立即学习“go语言免费学习笔记（深入）”；
- 国内用户必须设代理：
go env -w GOPROXY=https://goproxy.cn,direct；若用https://proxy.golang.org，90% 情况会超时 - 某些私有仓库（如 GitHub 私有 repo）需要认证：在
~/.netrc里加machine github.com login <token></token>，否则go mod tidy会反复 401 - 模块版本冲突：比如你
import "github.com/sirupsen/logrus"，但另一个依赖要求v1.9.0，而你代码里写了v2.0.0，go mod tidy会停在 resolve 阶段，需手动go get github.com/sirupsen/logrus@v1.9.0 - 最隐蔽的坑：项目根目录下有
vendor文件夹且未被.gitignore排除，go mod tidy会优先读vendor而不是远程模块，导致版本陈旧却不报错
go env 输出里那几行看似无关的路径，还有 go mod tidy 卡住时终端那一行不动的 “Fetching”。 
