Go 不自动加载 .env 文件，需手动用 godotenv 等库在 main() 开头加载；GOOS/GOARCH 是构建时变量，APP_ENV 等为运行时配置；避免 init() 中读环境变量，应封装 LoadConfig() 函数按需加载。
用 os.Getenv 读取环境变量前，先确保它被正确加载
Go 本身不自动加载 .env 文件，os.Getenv("APP_ENV") 返回空字符串不是代码写错了，而是环境变量根本没设。常见做法是启动时通过 shell 注入：APP_ENV=production go run main.go，或在 CI/CD 中显式 export。如果依赖 .env 文件，必须手动用第三方库（如 godotenv）加载，且要放在 main() 最开头，否则其他包初始化时就读不到。
区分 GOOS/GOARCH 和业务环境变量（APP_ENV、DB_HOST）
GOOS 和 GOARCH 是构建时的 Go 环境变量，影响二进制生成目标；而 APP_ENV 这类是运行时业务配置，两者生命周期和作用域完全不同。别试图用 build tags 控制数据库地址——那会导致编译出多个二进制，违背“一次构建、多环境部署”原则。真正该用 build tag 的只有极少数底层适配逻辑，比如 Windows 下用 NamedPipe、Linux 下用 Unix Socket。
避免在 init() 函数里读环境变量并赋值全局变量
这类写法看似方便，实则埋雷：
- 测试时无法重置或 mock，因为
init()只执行一次 - 不同包的
init()执行顺序不确定，可能config.go还没读完，db.go就已开始连接 - 一旦环境变量缺失，panic 发生在导入阶段，堆栈难定位
推荐方式：把配置封装成结构体，用函数按需加载，例如 LoadConfig() (*Config, error)，并在 main() 中显式调用。这样测试可传入 mock 环境，启动失败也能明确报错位置。
立即学习“go语言免费学习笔记（深入）”；
使用 viper 时注意覆盖优先级和热重载陷阱
viper 默认按“内置默认值 配置文件
-
viper.AutomaticEnv()不会自动把APP_ENV映射为app.env，需调用viper.SetEnvKeyReplacer(strings.NewReplacer(".", "_")) - 启用
viper.WatchConfig()后，若配置文件中写了log_level: debug，但环境变量同时设置了LOG_LEVEL=info，热更新后实际生效的是文件值，环境变量被覆盖——因为 watch 只监听文件，不监听环境变量变化
生产环境建议禁用热重载，改用进程重启（如 systemd reload 或 k8s rolling update）来切换配置。
环境变量不是魔法开关，它的加载时机、作用域和覆盖规则必须和项目启动流程对齐。最容易被跳过的其实是验证环节：上线前用go run -tags=prod main.go 启动，再立刻 curl /healthz 并检查日志里打印的 APP_ENV 是否真为 prod ——很多问题就卡在这一步。 
