应使用 os.LookupEnv 而非 os.Getenv，因其返回 (string, bool) 可明确区分“未设置”与“值为空”；需在启动时校验必填项，测试中显式设置环境变量，并避免在 init() 中读取。
怎么安全读取 GO_ENV 并 fallback
直接用 os.Getenv("GO_ENV") 读取环境变量是起点，但不加判断会立刻出错：它返回空字符串而非 nil，env == "production" 判断永远为 false。必须立刻兜底：
-
env := os.Getenv("GO_ENV")后立即检查：if env == "" { env = "development" } - 统一归一化大小写：
env = strings.ToLower(env)，避免"Dev"和"DEV"被当成不同环境 - 别在多个包里重复写这套逻辑——封装成全局唯一的
Env()函数，所有配置初始化都走这一入口 - 敏感字段（如
API_KEY、DB_URL）绝不 fallback，为空就log.Fatal("missing required env: DB_URL")
为什么不要拆 config_dev.go / config_prod.go
按环境拆配置文件看似清晰，实则引入三重风险：字段重复、合并冲突、测试难覆盖。Go 没有“条件编译”，这些文件会在构建时全被加载，容易因字段名/类型不一致导致静默覆盖或 panic。
正确做法是定义一个统一的 Config 结构体，在初始化阶段根据 Env() 动态填充：
- 数据库地址：
if env == "production" { cfg.DBURL = os.Getenv("DATABASE_URL") } else { cfg.DBURL = "localhost:5432" } - 日志级别：
cfg.LogLevel = map[string]string{"development": "debug", "production": "info"}[env] - YAML/JSON 文件只存非敏感、可版本化的参数（如重试次数、超时时间），敏感项一律由环境变量注入
viper.AutomaticEnv() 为什么是毒药
viper.AutomaticEnv() 会无差别映射所有环境变量（包括 HOME、PWD、SHELL），导致配置被意外覆盖。它不识别业务前缀，也不做校验。
立即学习“go语言免费学习笔记（深入）”；
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
如果必须用 viper，务必关掉自动映射：
- 调用
viper.DisableRemoteConfig()防止静默连接 etcd/consul - 禁用
viper.AutomaticEnv()，改用显式绑定：viper.BindEnv("server.port", "PORT") - 绝不用
viper.SetConfigName("config." + env)拼接文件名——Docker 镜像里通常不带多套 YAML 文件 - 纯环境变量场景，裸用
os.Getenv+ 结构体比引入 viper 更可控、更易测
测试时环境变量怎么可靠设置
APP_ENV=test go test ./ 在本地 shell 可能有效，但在 CI/CD 或 Docker 中完全失效：go test 子进程不继承父 shell 环境变量。
唯一可靠方案只有两个：
- 在
TestMain中显式设置：os.Setenv("GO_ENV", "test")，并用defer os.Unsetenv("GO_ENV")清理 - 把所有配置加载逻辑从
init()移出，收进NewConfig()函数——否则测试无法重置状态 - 测试中禁止连真实 DB 或发 HTTP 请求；把外部依赖抽象为接口，用 mock 实现验证
真正麻烦的不是读不到环境变量，而是读到了错误的值却没报错——比如 GO_ENV=prod 但 DB_URL 还是 localhost，服务照常启动，直到线上写坏数据才暴露。校验必须前置，且不可绕过。
