Go解析环境变量需分场景：纯读取用os.LookupEnv区分空值与未定义，绑定结构体需正确tag和指针，viper联动需设KeyReplacer、前缀及动态配置名，并严格控制加载顺序。
直接说结论：Go 里解析环境变量不是“读一下就完事”，而是要分清场景——是纯读取、绑定结构体、还是和配置文件联动。用错方式，viper.GetString("db.host") 返回空、os.Getenv("PORT") 拿不到值、甚至启动报 Config File Not Found，全是常态。
os.Getenv 和 os.LookupEnv 的区别在哪
两者都从进程环境读，但行为完全不同：os.Getenv 返回空字符串表示“没设”，os.LookupEnv 返回 (value, exists) 二元组，能真正区分“值为空”和“变量未定义”。比如 DB_PASS="" 是合法的（空密码），但 os.Getenv("DB_PASS") == "" 无法判断是空还是没设。
-
os.Getenv适合有默认值兜底的场景，如port := os.Getenv("PORT"); if port == "" { port = "8080" } -
os.LookupEnv更安全，尤其校验必填字段，如if host, ok := os.LookupEnv("DB_HOST"); !ok { log.Fatal("DB_HOST required") } - 两者都不做类型转换，拿到的永远是
string，后续需手动转int、bool等
viper 绑定环境变量时点号不生效怎么办
viper.BindEnv("server.port") 默认去找名为 SERVER.PORT 的环境变量，但系统里实际是 SERVER_PORT —— 点号没自动转下划线，字段就永远绑不上。
- 必须提前调
viper.SetEnvKeyReplacer(strings.NewReplacer(".", "_"))，让server.port映射到SERVER_PORT - 加统一前缀避免命名冲突：
viper.SetEnvPrefix("app")，这样app.server.port对应APP_SERVER_PORT - 非标准映射要显式绑定：
viper.BindEnv("db.host", "PGHOST")，适用于 PostgreSQL 原生环境变量 - 别漏掉
viper.AutomaticEnv()，否则BindEnv不会自动触发读取
viper 多环境配置文件 + 环境变量混合加载的坑
常见错误是硬编码 viper.SetConfigName("config-prod")，结果 ENV=dev 启动直接报 Config File Not Found。viper 不会根据环境变量自动补后缀。
立即学习“go语言免费学习笔记（深入）”；
-
viper.SetConfigName必须动态拼接：viper.SetConfigName("config-" + os.Getenv("ENV"))（推荐小写ENV） -
AddConfigPath路径必须真实存在且可读，./configs不存在就 panic -
SetConfigType必须在ReadInConfig()前调，否则报Unsupported Config Type "" - 敏感字段（如密码）建议只从环境变量读，不写进 YAML 文件，用
viper.BindEnv("db.password", "DB_PASSWORD")单独绑定
结构体 unmarshal 后字段为空的真正原因
不是配置没加载，而是 Go 的反射机制对字段名极其严格。yaml 解析、viper unmarshal 都依赖 struct tag，且大小写、导出性、拼写一个都不能错。
- 字段必须首字母大写（导出），否则
yaml.Unmarshal写不进去 - 必须显式声明
yaml:"host"tag，且内容与 YAML 文件中 key 完全一致（host≠Host） - 嵌套结构体也要打 tag：
Server ServerConfig `yaml:"server"`，不能靠字段名自动推导 - 如果用了
viper.Unmarshal(&cfg)，确保cfg是指针，且所有嵌套结构体字段都有对应 tag
最易被忽略的是：环境变量加载顺序和优先级。viper 默认是“文件 → 环境变量 → 默认值”，但如果你先 BindEnv 再 ReadInConfig，环境变量就会覆盖配置文件里的同名字段；反过来，如果先 ReadInConfig 再 BindEnv，又可能被覆盖两次。这个顺序得按你的真实需求手动控制，没有银弹。
