直接用os.Getenv读环境变量会导致值为空不报错、类型需手动转换、测试难mock、字段名分散，易引发panic和维护困难；推荐用caarlos0/env封装为导出结构体并加env tag，启动时统一校验、自动处理fallback与类型转换，测试可传map隔离环境。
直接用 os.Getenv 读环境变量会出什么问题
值为空时不报错、类型要自己转、测试难 mock、字段名散落在各处——这些不是“小问题”，而是上线后踩坑的常见源头。比如 os.Getenv("DB_PORT") 返回空字符串，strconv.Atoi 一调就 panic；又比如测试时想模拟生产环境，得反复改系统环境变量或写 shell 脚本，根本没法并行跑。
用 caarlos0/env 封装结构体是更稳的做法
把所有配置字段收进一个导出结构体，用 env tag 声明映射关系，启动时统一校验：
type Config struct {
DBHost string `env:"DB_HOST" default:"localhost"`
DBPort int `env:"DB_PORT" default:"5432"`
Debug bool `env:"DEBUG" default:"false"`
}
func LoadConfig() (*Config, error) {
cfg := &Config{}
if err := env.Parse(cfg); err != nil {
return nil, err
}
return cfg, nil
}
-
env.Parse自动处理空值 fallback、类型转换、required 校验（加required:"true"tag 即可） - 测试时传入
map[string]string模拟环境变量，完全隔离系统状态 - 字段必须导出（首字母大写），否则
env库读不到 - 敏感字段（如密码）别设
default，改用required:"true"
开发阶段用 godotenv 加载 .env 文件，但要注意覆盖逻辑
godotenv.Load(".env") 不会覆盖已存在的环境变量，而 godotenv.Overload() 才会。本地开发建议按顺序加载：
- 先
godotenv.Load(".env.local")（本地覆盖） - 再
godotenv.Load(".env")（基础配置） - CI/CD 流水线里禁用
.env*加载，只认真实环境变量 - 别在
init()里调Load，否则单元测试无法控制时机
纯 Go 项目慎用 viper，尤其在容器部署场景
它默认开启远程监听（etcd/consul），不关会静默失败；同时启用 viper.AutomaticEnv() 和 viper.SetEnvPrefix("APP") 会导致变量名变成 APP_DB_HOST，而你实际只设置了 DB_HOST——根本读不到。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
如果真要用 viper，务必显式关闭不需要的功能：
viper.DisableRemoteConfig() viper.AutomaticEnv() // 不要 SetEnvPrefix，除非你明确需要前缀
真正容易被忽略的是：环境变量优先级和加载时机。同一份代码，在 Docker 容器里靠 ENV 指令注入，在 Kubernetes 里靠 envFrom 注入，在本地开发靠 .env 文件——三者行为不一致时，问题往往出在加载顺序或覆盖逻辑上，而不是配置本身。
