viper配置加载必须严格遵循顺序：先setconfigname、addconfigpath、automaticenv，再readinconfig；否则环境变量不覆盖、路径错误或unmarshal静默失败。
Go 项目里配置读取不是“调个 viper.ReadInConfig() 就完事”，它是一条有明确顺序、依赖关系和隐式规则的链路。错一步，viper.Get("db.host") 就可能返回空字符串或零值，而你查半天发现是加载时机或路径设置错了。
为什么 viper.AutomaticEnv() 必须在 viper.ReadInConfig() 前调用
环境变量覆盖不是“自动生效”的魔法，而是靠 viper 内部的键映射表驱动的。调用 viper.AutomaticEnv() 时，它会扫描所有已注册的配置键（比如你后面 ReadInConfig() 加载的 server.port），并把对应环境变量（如 SERVICE_PORT）映射进来。如果先 ReadInConfig()，配置已经固化进内存了，再调 AutomaticEnv() 就没用了。
- 错误顺序：
viper.ReadInConfig()→viper.AutomaticEnv()→ 环境变量完全不参与覆盖 - 正确顺序：
viper.SetConfigName("config")→viper.AddConfigPath("./configs")→viper.AutomaticEnv()→viper.ReadInConfig() - 若需显式绑定某个环境变量，用
viper.BindEnv("log.level", "LOG_LEVEL")，它比AutomaticEnv()更精准，且不受调用顺序影响
viper.Unmarshal() 的静默失败风险
直接 viper.Unmarshal(&cfg) 看似省事，但 Go 反射对字段可见性、嵌套结构、类型转换都不报错——它只是跳过无法赋值的字段，然后默默返回 nil 错误。你拿到一个半空的 cfg，业务却照常跑，直到某天 cfg.TimeoutSeconds 是 0 才暴露问题。
- 必须确保结构体字段首字母大写（导出），否则
Unmarshal完全忽略该字段 - 嵌套结构（如
Database）建议用viper.Sub("database").Unmarshal()单独解包，避免顶层结构体字段名与配置 key 不一致导致漏映射 - 更推荐组合：用
viper.GetInt("server.port")或viper.GetString("log.level")显式取值+类型断言，出错时能立刻定位到具体 key
多环境配置路径该怎么组织才不混乱
把 dev.yaml、prod.yaml 全塞进同一目录，靠 viper.SetEnvKey("ENV") 切换，容易漏加 viper.BindEnv("env") 或拼错环境名。更稳的方式是让环境名成为配置路径的一部分，让文件系统帮你做隔离。
- 目录结构示例：
configs/dev/config.yaml、configs/prod/config.yaml - 代码中动态加载：
viper.AddConfigPath(fmt.Sprintf("configs/%s", env))，其中env := viper.GetString("env")从命令行或环境变量取 - 这样不用 if-else 分支判断不同环境逻辑，也不用维护一堆
BindEnv映射，加载失败时路径错误一目了然 - 注意：路径中不能含通配符，
viper不支持configs/*这种写法
真正卡住人的从来不是语法，而是加载顺序、路径拼接、字段导出这些细节——它们不报错，只悄悄让配置变成默认值。每次改配置，先确认 viper.AllKeys() 输出是否包含你期望的 key，比反复重启服务查日志快得多。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
