Go 1.16+默认启用模块，go build失败本质是模块感知问题：在模块根目录需有main.go，否则退化为单文件编译；GOBIN不设则go install输出至$HOME/go/bin但不在PATH中；CGO_ENABLED=0是否必需取决于是否使用cgo及目标环境libc兼容性。
Go 1.16 是分水岭：之前靠 GOPATH，之后默认启用模块（go mod），不设 GOROOT 也能跑，但没设 GOBIN 容易找不到 go 工具生成的二进制。
为什么 go build 在项目根目录失败，却在子目录能成功？
本质是模块感知问题。Go 从 1.11 开始按“是否在模块内”切换行为：
- 如果当前目录或任意上级有
go.mod，go build默认构建当前模块的main包（要求main.go在当前目录） - 如果不在模块中，
go build退化为旧式“单文件编译”，只编译当前目录下所有.go文件 —— 所以子目录里放着独立main.go反而能过 - 常见误操作：用
go mod init初始化后忘了把main.go放到模块根，或go.mod里module声明路径和实际目录结构不一致
GOBIN 不设置，go install 生成的可执行文件去哪了？
Go 1.17+ 默认将 go install 输出写入 $HOME/go/bin（非 $GOROOT/bin），但这个路径不会自动加入 $PATH。结果就是命令敲得出来，系统找不到：
- 运行
go install ./cmd/myapp后，二进制实际落在$HOME/go/bin/myapp - 若
$HOME/go/bin不在$PATH中，终端直接执行myapp会报command not found - 验证方式：运行
go env GOBIN看输出；用ls $(go env GOBIN)确认文件是否存在 - 修复只需一行：
export PATH="$(go env GOPATH)/bin:$PATH"（注意不是GOBIN，是GOPATH/bin）
交叉编译时 CGO_ENABLED=0 必须加吗？
取决于你是否用了 cgo 依赖（比如 net 包在 Linux 下默认用 cgo 解析 DNS，Windows/macOS 则不用）：
立即学习“go语言免费学习笔记（深入）”；
- 加
CGO_ENABLED=0：纯静态链接，生成的二进制无外部依赖，但部分功能降级（如 DNS 解析走 Go 自带逻辑，可能不兼容某些企业内网配置） - 不加：动态链接 libc，体积小、功能全，但目标机器必须有对应 libc 版本（例如在 CentOS 7 编译的二进制，在 Alpine 上大概率运行失败）
- 典型陷阱：本地开发机是 macOS，
go build默认CGO_ENABLED=1，但 CI 构建用 Ubuntu Docker 镜像，若未显式设CGO_ENABLED=0，生成的二进制可能因 libc 版本差异在 Alpine 容器里 panic
模块路径声明、GOBIN 路径归属、cgo 的隐式开关——这些都不是文档里标红加粗的“必须项”，但每个都卡在编译成功的最后一厘米上。
