go build跨平台需显式设置goos和goarch，否则仅生成当前系统架构二进制；cgo_enabled=0是纯go项目静态跨编译前提；viper环境变量覆盖配置文件需重置并调整加载顺序；os.lookupenv比os.getenv更可靠地区分未定义与空值。
go build 时 GOOS 和 GOARCH 必须显式设置
不设这两个变量，go build 默认只生成当前系统架构的二进制——比如在 macOS 上跑 go build，永远得到 darwin/amd64，哪怕你目标是 Linux ARM64。这不是 bug，是 Go 的默认行为。
验证支持哪些组合，直接运行：go tool dist list。输出里没有的组合（比如旧版 Go 不支持 darwin/arm64），硬设会报 unsupported GOOS/GOARCH pair。
- Linux ARM64：
GOOS=linux GOARCH=arm64 go build -o app main.go - Windows AMD64：
GOOS=windows GOARCH=amd64 go build -o app.exe main.go（注意后缀） - macOS Intel：
GOOS=darwin GOARCH=amd64 go build -o app-darwin main.go
CGO_ENABLED=0 是跨平台静态编译的前提
默认 CGO_ENABLED=1，Go 会尝试调用宿主机的 C 工具链（如 libc、windows.h）。跨平台时，你的 macOS 机器没有 Windows 的头文件，编译直接失败。
纯 Go 项目（没 #include、没调 C. 函数、没依赖 cgo 包）可以安全关掉：CGO_ENABLED=0 GOOS=linux GOARCH=arm64 go build -o app main.go。
但一旦用了 github.com/mattn/go-sqlite3 这类含 C 的包，CGO_ENABLED=0 会报 undefined: _Ctype_int。此时只能：在目标平台本地构建，或用 Docker 模拟目标环境（例如 docker run --rm -v $(pwd):/src -w /src golang:1.21-alpine go build -o app main.go）。
viper 读环境变量必须控制加载顺序
viper.AutomaticEnv() 本身不生效，是因为它注册的环境变量源默认排在最后——比 config.yaml 优先级还低。结果就是配置文件值永远盖过环境变量。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
正确做法分三步：
- 先
viper.Reset()（尤其测试中容易漏） - 再
viper.SetConfigFile("config.yaml")+viper.ReadInConfig() - 然后
viper.SetEnvPrefix("APP")+viper.AutomaticEnv()+viper.SetEnvKeyReplacer(strings.NewReplacer(".", "_"))
这样环境变量才真正“覆盖”配置文件。例如 APP_DB_HOST=localhost 就能覆盖 config.yaml 里的 db.host。
os.LookupEnv 比 os.Getenv 更可靠
os.Getenv("FOO") 返回空字符串，你根本分不清是变量没设，还是被设成了 ""。这对配置逻辑很危险——比如你认为 DB_URL 为空就走默认值，结果其实是用户显式清空了它。
改用 os.LookupEnv：
value, ok := os.LookupEnv("DB_URL")
if !ok {
// 环境变量根本未定义，走 fallback
}
// value 可能是 ""，但至少你知道它是被设过的
另外注意：Windows 环境变量名大小写不敏感（Path 和 PATH 等价），Linux/macOS 完全区分大小写。别在脚本里混用 FOO 和 foo。
secrets、容器里的 envFrom、本地 .env 文件——这些源头的加载时机、作用域、是否透传到子进程，每一步都可能断掉。别只盯着 Go 代码怎么读，先确认变量真正在进程里存在。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
