Viper 不自动识别环境，必须手动拼接配置文件名；正确做法是 viper.SetConfigFile("config." + env + ".yaml")，配合 AddConfigPath、SetConfigType，并校验 env 值与文件存在性。
Viper 本身不支持“自动识别微服务环境”——它只负责读配置，环境判断和加载逻辑必须你自己写清楚，否则多环境切换时会加载错文件或覆盖出错。
为什么 viper.SetConfigName("config") 不能解决多环境问题
这个函数只设置基础配置名，不带环境上下文。Viper 默认按顺序查找：config.json → config.yaml → … 它不会自动找 config.dev.yaml 或 config.prod.yaml。你得手动告诉它该读哪个文件，否则所有环境都读同一个 config.yaml，根本谈不上隔离。
- 常见错误现象：本地跑
go run main.go加载了config.prod.yaml，因为没指定环境，Viper 找到的第一个匹配文件就被用了 - 正确做法是把环境名作为变量参与路径拼接，比如
viper.SetConfigFile("config." + env + ".yaml") - 注意
SetConfigFile()和SetConfigName()互斥：一旦调用前者，后者就失效；多环境场景建议只用SetConfigFile() - 如果用
ReadInConfig()前没调SetConfigFile()且没设viper.AddConfigPath()，会 panic 报错"Config File 'config' Not Found in path"
如何安全传入环境变量并避免硬编码
别在代码里写 env := "prod"，也不要用 os.Getenv("ENV") 后直接拼接——万一环境变量为空或拼写错误（比如 "prodd"），Viper 会静默加载失败，然后 fallback 到零值，极难排查。
- 推荐方式：用命令行参数优先，环境变量兜底，再加默认值校验
env := flag.String("env", os.Getenv("APP_ENV"), "environment: dev/staging/prod")flag.Parse()
然后检查：if *env != "dev" && *env != "staging" && *env != "prod" { log.Fatal("invalid APP_ENV") } - 路径构造要绝对可靠：
viper.SetConfigFile(filepath.Join("configs", "config."+*env+".yaml"))，确保configs/目录存在且可读 - 避免用
viper.AutomaticEnv()自动映射所有环境变量——它会把DB_HOST映射成db.host，但如果你的 YAML 里字段是database.host，就对不上，造成配置缺失
嵌套结构、类型转换与热重载的现实约束
Viper 对嵌套字段（如 database.url）支持良好，但要注意：YAML 中的 null、空字符串、未定义字段，在 Go struct 中会被转成零值，且 viper.Get() 返回 interface{}，直接断言易 panic。
立即学习“go语言免费学习笔记（深入）”；
- 务必用强类型方法取值：
viper.GetString("server.port")、viper.GetInt("log.level")，它们内部做了类型安全检查和默认值 fallback - 不要依赖
viper.WatchConfig()实现配置热重载——它只监听文件变化并触发回调，但不会自动重新绑定 struct 或更新已初始化的全局变量（比如dbConn），业务层需自己 reload 连接池、重置限流器等 - 微服务中常见陷阱：多个包各自调
viper.UnmarshalKey("redis", &r)，但没加锁，导致并发读写 map panic；应统一在启动时解析一次，存为只读 struct 全局变量 - 性能提示：Viper 的
Get*方法有缓存，但首次解析 YAML 开销较大；若配置项极少（如仅 3–5 个），直接用gopkg.in/yaml.v3反序列化可能更轻量
最常被忽略的一点：Viper 不校验配置字段是否存在。比如 YAML 里漏写了 jwt.secret，而代码里直接 viper.GetString("jwt.secret")，返回空字符串——服务可能正常启动，但鉴权永远失败。必须在启动时显式检查关键字段是否非空，不能靠“运行时出错再看日志”。
