跨平台编译必须显式设置CGO_ENABLED=0，否则默认链接目标系统C库导致二进制不兼容；若确需CGO，则须为各平台单独交叉编译C依赖，推荐优先选用纯Go替代方案。
GOOS和GOARCH跨平台编译必须关掉CGO
本地能跑不代表目标平台能跑，根本原因常出在CGO上。只要CGO_ENABLED=1（默认值），Go就会链接系统C库，导致Linux编译的二进制在Windows上直接报exec format error，或macOS上提示cannot execute binary file。
正确做法是显式禁用：CGO_ENABLED=0 GOOS=windows GOARCH=amd64 go build -o app.exeCGO_ENABLED=0 GOOS=linux GOARCH=arm64 go build -o app-linux-arm64
- 所有涉及跨平台编译的CI脚本、Makefile里，
CGO_ENABLED=0必须写死，不能依赖环境默认值 - 如果项目真依赖C库（如sqlite、openssl），得为每个目标平台单独交叉编译C部分，成本陡增，多数场景应优先找纯Go替代方案
-
go env -w CGO_ENABLED=0全局设置不可取——会破坏本地开发时需要CGO的调试场景
GO111MODULE=on不是可选项，是强制前提
Go 1.16起默认开启Modules，但旧项目或手动配置失误时仍可能 fallback 到GOPATH模式，导致go get行为异常、依赖路径错乱、vendor目录失效。
验证方式：go env GO111MODULE —— 输出必须是on，不是auto或空
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 项目根目录下必须存在
go.mod文件，哪怕只是module example.com/foo一行 - 执行
go mod init后立即运行go mod tidy，否则go build可能漏拉间接依赖 - CI环境中禁止用
go get动态装工具（如golangci-lint），应预装或用固定镜像，避免GO111MODULE=off导致的模块解析失败
GOPROXY和GOSUMDB必须成对调整
设了国内代理却没关校验，go mod download会卡住或报checksum mismatch；反之关了校验却用默认代理，又可能拉到被篡改的包。
推荐组合（国内环境）：go env -w GOPROXY=https://goproxy.cn,directgo env -w GOSUMDB=off
-
GOSUMDB=off仅限开发/测试环境，生产CI建议保留GOSUMDB=sum.golang.org并配可信代理 - 若团队用私有仓库，
GOPROXY需指向内部代理（如Athens），同时GOSUMDB设为对应校验服务地址 - 执行
go mod verify应在CI中作为独立步骤，而非依赖go build隐式触发
GOROOT和GOBIN路径冲突是Windows高频雷区
Windows用户常把Go解压到D:\go，再手动设GOROOT=D:\go，但go install生成的工具（如protoc-gen-go）默认落到%USERPROFILE%\go\bin，而PATH里只加了%GOROOT%\bin，结果命令行始终找不到工具。
立即学习“go语言免费学习笔记（深入）”；
解法只有两个：
① 统一用GOBIN控制输出位置：go env -w GOBIN=%USERPROFILE%\go\binset PATH=%USERPROFILE%\go\bin;%PATH%
② 或彻底弃用GOROOT，直接把解压后的go\bin加进PATH（官方安装包默认做法）
- 不要混用
go install和go get——后者在Go 1.20+已废弃，go install some/tool@latest才是正途 -
go env -w GOPATH可以设，但go mod项目里它只影响go install的默认落点，不参与依赖管理 - VS Code的Go插件会读
go env输出，PATH错则插件提示“Go command not found”，别急着重装插件，先查环境变量
GOOS/GOARCH、CGO_ENABLED、GO111MODULE这三组开关的组合状态——它们互相耦合，改一个常牵出另外两个问题。 
