go环境真正就绪需验证goroot和gobin未被手动污染、go111module=on、跨平台构建约束正确、工具链路径在path中，且gopls等依赖go env而非旧配置。
go 命令能跑起来，不代表你的 Go 环境真的 ready 了——尤其当你开始用 go mod、交叉编译、或者调试 CGO_ENABLED=1 的项目时，缺一个环节就卡住。
怎么确认 GOROOT 和 GOBIN 没被手动污染
很多人装完 Go 就急着改 GOROOT，结果 go install 装的工具（比如 gopls、delve）找不到，或者 go build -o 输出路径诡异。官方二进制包安装后，GOROOT 应该指向解压目录（如 /usr/local/go），且**不要手动设置它**——go 会自己推导。GOBIN 同理：默认是 $GOPATH/bin，如果你设了，就得确保它在 $PATH 里，否则 go install 出来的命令根本执行不了。
- 检查方式：
go env GOROOT和go env GOBIN，输出路径是否合理、是否存在 - 如果
GOROOT指向你随便建的空目录，删掉这个环境变量，重开终端 -
GOBIN只有在想统一管理工具路径时才设；设了就必须export PATH=$GOBIN:$PATH
go mod init 报错 “module root not in GOPATH” 怎么办
这是 Go 1.13+ 的常见错觉——其实不是真要你在 $GOPATH/src 下操作，而是当前目录没匹配任何已知模块路径，且 GO111MODULE 没明确启用。Go 早就默认开启 module 模式了，但某些旧 shell 配置或 IDE 插件会把它关掉。
- 先运行
go env GO111MODULE，如果不是on，就加到 shell 配置里：export GO111MODULE=on -
go mod init的参数必须是合法的模块路径，比如github.com/yourname/project，不能是./project或空字符串 - 如果项目已有
vendor/目录，go mod init会失败；先删 vendor 或用go mod init -modfile=go.mod.old迁移
为什么 go build 在 macOS 上成功，Linux 上却报 undefined: syscall.Statfs
这不是环境问题，是构建约束（build constraint）没处理好。macOS 和 Linux 对 syscall 的封装不同，直接调用底层结构体容易跨平台失效。尤其当你从 Cgo 或 syscall 包抄代码时，很容易忽略这点。
- 优先用
os.Stat()、os.ReadDir()这类跨平台 API，而不是硬写syscall.Statfs - 必须用系统调用时，在文件顶部加构建注释：
//go:build linux，并确保对应文件只在目标平台编译 - 交叉编译前务必清掉缓存：
go clean -cache -modcache，否则旧的 .a 文件可能混入不兼容符号
VS Code 里 gopls 一直 restarting，go 命令行正常
说明语言服务器和你的 workspace 配置对不上——最常见的是 go.gopath 或 go.toolsGopath 被手动填了值，而 gopls 现在完全依赖 go env，不再认这些配置项。
- 打开 VS Code 设置，搜
go.gopath，删掉它的值（留空） - 检查工作区根目录是否有
go.work文件；如果有，确保里面use的路径都存在，且每个路径下都有go.mod - 重启 VS Code 后，在命令面板运行
Go: Install/Update Tools，勾选gopls单独重装
go test 突然慢了三倍，或者 go run main.go 找不到刚 go install 的本地工具——那往往是因为某个环境变量悄悄变了，或者 go.work 和 go.mod 的作用域叠在一起了。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
