Go环境验证需检查三件事：which go输出路径、go env GOROOT指向正确安装目录、go env GOPATH与模块使用逻辑匹配；跨平台部署须用CGO_ENABLED=0静态编译；IDE报错多因未加载shell环境变量。
Go 环境不用装一堆工具链，go 命令本身就能覆盖绝大多数开发需求。只要 GOROOT 和 PATH 设置正确，go build、go run、go mod 都能直接用，不需要额外配置构建器或 IDE 插件。
怎么验证 Go 是否真可用，而不是“看起来装好了”
很多人执行 go version 返回了版本号就以为万事大吉，但实际运行时可能报 command not found 或 cannot find module。关键要看三件事：
-
which go必须输出路径（如/usr/local/go/bin/go），否则说明PATH没生效 -
go env GOROOT应该指向解压后的 Go 安装根目录（如/usr/local/go），不是$HOME/go这类常见误配 -
go env GOPATH在 Go 1.16+ 默认是$HOME/go，但如果你用go mod，它其实不参与模块查找——真正起作用的是当前目录下有没有go.mod
go build 编译出的二进制为什么在别的机器跑不了
默认 go build 生成的是动态链接可执行文件，依赖目标机器上的 libc 和系统库。常见现象是：在 CentOS 7 编译的二进制，拷到 Alpine 容器里直接报 not found。
- 加
-ldflags '-s -w'可去掉调试信息、减小体积（-sstrip symbol，-womit DWARF debug info） - 跨平台或容器部署，必须静态编译：
CGO_ENABLED=0 go build -o myapp - 如果代码里用了
cgo（比如调用 SQLite 或 OpenSSL），CGO_ENABLED=0会直接失败，这时得换基础镜像（如golang:alpine+apk add --no-cache git musl-dev）
为什么 go mod init 后 go build 还报 missing required module
这不是环境问题，是 Go Modules 的导入路径和实际目录结构不匹配导致的。典型场景：
立即学习“go语言免费学习笔记（深入）”；
- 你在
/tmp/myproj下执行go mod init example.com/foo，但代码里写的是import "github.com/user/bar"—— 路径对不上，go build就找不到包 - 项目根目录下没有
go.mod，却在子目录里执行go build，Go 会向上找最近的go.mod，找不到就退化成 GOPATH 模式，而 GOPATH 模式下main.go必须放在$GOPATH/src/...里才认 - 用
go build ./...时，如果某个子目录含非法 import（比如空包名、循环引用），整个命令会失败，但错误提示只说 “missing module”，不指明哪一行
LiteIDE 或 VS Code 里运行报错，终端里却正常
这类问题几乎全是 IDE 没读取 shell 的环境变量，尤其是 GOROOT 和 PATH。VS Code 默认启动时用的是系统级 shell 环境（Linux/macOS 是 /bin/sh），不是你日常用的 bash 或 zsh 配置。
- LiteIDE 启动前手动设置：
export GOROOT=/usr/local/go; export PATH=$GOROOT/bin:$PATH，再运行liteide - VS Code 用户，在
settings.json加："go.goroot": "/usr/local/go"，同时确保terminal.integrated.env.linux包含完整PATH - 不要依赖 IDE 自动探测——它常把
/usr/bin/go（系统旧版）当首选，而你实际装的是/usr/local/go
最麻烦的从来不是安装步骤，而是不同上下文（shell / IDE / Docker / CI）之间环境变量的隐式差异。每次卡住，先 echo $GOROOT && which go，别猜。
