go环境搭建成功需验证三件事：go命令可用（go version输出版本）、模块模式生效（go env gomod返回go.mod路径）、goos/goarch能识别平台；其余均为可选配置。
Go语言环境搭建成功与否，只看三件事：go 命令是否可用、GOPATH（或模块模式）是否生效、GOOS/GOARCH 是否能正确识别当前平台。其余配置项都是可选的延伸，不是“能不能跑”的决定因素。
验证 go 命令和版本是否就位
这是最基础也最容易被跳过的一步。很多人解压完 Go 二进制包，却忘了把 /usr/local/go/bin（Linux/macOS）或 C:\Go\bin（Windows）加进 PATH。
- 执行
go version，必须输出类似go version go1.21.3 linux/amd64—— 如果报command not found或'go' is not recognized，说明 PATH 没配对 - 执行
which go（Linux/macOS）或where go（Windows），确认路径指向你安装的 Go 目录，而非旧版本残留 - 注意：Go 1.16+ 默认启用模块（module）模式，
GO111MODULE=on已是默认行为，无需手动设置；但若项目里有go.mod却提示“no required module provides package”，大概率是当前目录不在模块根下，或go mod init没运行
区分 GOPATH 模式与 module 模式
Go 1.11 引入 module 后，GOPATH 不再是必需项，但它的存在仍会影响行为，尤其在老项目或 CI 环境中。
- 新建项目时，直接在空目录执行
go mod init example.com/myapp，即可启用 module 模式，此时GOPATH对依赖下载路径无影响，所有依赖存于go/pkg/mod - 若未初始化 module，且当前目录不在
$GOPATH/src下，go build会报错no Go files in ...—— 这不是环境问题，而是项目结构不满足 GOPATH 旧约定 -
go env GOPATH可查当前值，但只要go mod能正常工作，这个值实际已退居二线；真正要盯的是go env GOMOD，它应返回当前项目的go.mod路径，为空则说明 module 未激活
跨平台编译支持是否可用
Go 的跨平台能力不是“装了就能用”，它依赖 CGO 和底层工具链。默认情况下，纯 Go 代码（不含 cgo）可直接跨平台编译；一旦用了 net、os/user 等包，就可能触发 CGO，此时需额外准备。
- 执行
GOOS=linux GOARCH=amd64 go build -o test-linux main.go，若报错exec: "gcc": executable file not found in $PATH，说明 CGO 开启且缺少 C 编译器 —— 此时可临时禁用：CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o test-linux main.go -
go env GOOS和go env GOARCH显示当前构建目标，不是“默认编译平台”，只是环境变量快照；它们不影响go run，只影响go build的默认输出目标 - Windows 上若想交叉编译 Linux 二进制，
CGO_ENABLED=0是最简方案；如需 CGO 支持（比如调用 OpenSSL），就得装 MinGW-w64 或 WSL2 内的 GCC
真正容易被忽略的，是 go.mod 文件的存在与否和位置——它不像 .gitignore 那样能靠直觉感知，但一旦缺失或放错目录，go get、go build 就会静默退回到 GOPATH 模式，导致依赖路径混乱、升级失败、vendor 失效。每次新建项目，第一行命令应该是 go mod init，而不是直接写代码。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
