必须加CGO_ENABLED=0，否则跨平台编译会因cgo依赖宿主机C工具链（如gcc、libc）而失败，报错“exec: 'gcc' not found”或“cannot use cgo”；禁用后走纯Go实现，生成静态二进制。
go build 交叉编译时 CGO_ENABLED=0 必须加
不加 CGO_ENABLED=0，go build 在跨平台编译（比如 Linux 二进制在 macOS 上构建）时大概率失败，报错类似：exec: "gcc": executable file not found in $PATH 或 cannot use cgo。
原因很直接：Go 默认启用 cgo，而 cgo 依赖宿主机的 C 工具链（如 gcc、libc 头文件）。目标平台（如 linux/amd64）的 libc 和 macOS 的 libc 不兼容，不关 cgo 就没法干净打包。
-
CGO_ENABLED=0强制禁用 cgo，所有系统调用走纯 Go 实现（net、os、syscall 等模块有纯 Go 后备路径） - 适用于绝大多数 CLI 工具、HTTP 服务、无 CGO 依赖的项目；但若用了
net.LookupIP（默认走 cgo）、sqlite 驱动、或调用 C 库，则需另作处理 - Windows → Linux 编译必须加；macOS → Windows 同理；Linux → macOS 也建议加，避免因 Darwin SDK 路径问题中断
go build -o 和交叉编译不能共存
go build -o output_name 在设置 GOOS/GOARCH 时会直接报错：flag provided but not defined: -o —— 这不是 bug，是 Go 工具链的明确限制。
根本原因是：当指定目标平台时，go build 内部会切换为“模块感知 + 构建缓存”模式，-o 会被解析器提前拒绝。解决方式只有两种：
立即学习“go语言免费学习笔记（深入）”；
- 先 cd 到项目根目录（含
go.mod），再执行：CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o ./dist/app-linux . - 或分两步：先构建临时二进制（不带
-o），再用mv重命名（仅限单包项目，且注意默认名含.exe后缀） - 别写成
go build -o ./dist/app-linux.go——-o后跟的是输出路径+文件名，不是源文件名
GOROOT 和 GOPATH 现在到底还要不要设？
Go 1.16+ 默认启用 modules，GOPATH 已非必需；但 GOROOT 必须正确，否则 go 命令根本跑不起来。
验证方式很简单：go env GOROOT 输出应是非空有效路径（如 C:\Program Files\Go 或 /usr/local/go）；而 go env GOPATH 即使为空也不影响模块项目构建。
- IDE（如 GoLand、VSCode）启动时会读
GOROOT来定位go二进制和标准库，配错就提示 “Go SDK not found” -
GOPATH若被显式设置，仍会影响go install的安装位置（$GOPATH/bin），但日常go run/go build不依赖它 - Windows 用户尤其注意：安装 MSI 包通常自动设好
GOROOT和PATH，但若手动解压 ZIP 包，必须自己设GOROOT并把%GOROOT%\bin加入PATH
go mod vendor 后 go build 仍联网？
执行了 go mod vendor，但 go build 过程中还是尝试访问 proxy（如 proxy.golang.org），说明 vendor 没生效或被绕过。
关键检查点只有两个：
- 确认当前目录下存在
vendor/目录，且非空；同时go.mod中有// indirect注释行（表示 vendor 已生成） - 必须加
-mod=vendor参数运行：go build -mod=vendor -o app .；不加该 flag，Go 默认仍走网络拉取 - 如果用了
replace指向本地路径（如replace example.com/lib => ../lib），vendor 不会包含这些路径，-mod=vendor会直接失败 —— 此时只能删掉replace或改用go mod edit -replace指向已 vendored 的副本
真正麻烦的从来不是命令记不住，而是环境变量、cgo 开关、vendor flag 这三者之间的隐式耦合 —— 少一个，编译就卡在不同环节，报错还未必指向真实原因。
