Viper 本身不支持自动合并多个同名但不同环境的配置文件，必须手动控制加载顺序、显式调用 ReadInConfig() 或 UnmarshalKey() 多次，并用 Go 代码实现结构合并；其 ReadInConfig() 仅查找并读取第一个匹配文件，而非遍历叠加，且 Sub() 才是安全访问嵌套配置的可靠方式。
直接说结论：Viper 本身不支持“自动合并多个同名但不同环境的配置文件”，所谓多源配置，本质是手动控制加载顺序 + 显式调用 ReadInConfig() 或 UnmarshalKey() 多次，再靠 Go 代码做结构合并；语言学习工程化规范不是 Viper 的职责，而是你得在项目里约束路径、命名、类型断言和 fallback 行为。
为什么 ReadInConfig() 只加载一个文件，而不是按环境叠加
Viper 的 ReadInConfig() 是“查找并读取第一个匹配文件”逻辑，不是“遍历所有匹配文件并合并”。它按 AddConfigPath() 添加顺序扫描路径，再按内置后缀列表（["json", "yaml", "yml", "toml", ...]）尝试扩展名——但只成功一次就停。比如你设了 SetConfigName("config")，加了两个路径："configs/base" 和 "configs/dev"，它可能先在 base 找到 config.yaml 就直接加载，根本不会去 dev 路径下找同名文件。
- 想加载 base + dev，必须分两次调用：
viper.AddConfigPath("configs/base"); viper.ReadInConfig()，再viper.AddConfigPath("configs/dev"); viper.ReadInConfig()，但第二次会完全覆盖第一次——除非你提前用viper.Sub()提取 base 数据存起来 - 更稳妥的做法是用
viper.MergeConfigMap()：先UnmarshalKey("database", &baseDB)，再UnmarshalKey("database", &devDB)，然后手动 merge 字段 -
SetConfigFile("configs/base/config.yaml")+SetConfigFile("configs/dev/config.yaml")不行——SetConfigFile()只能设一次，第二次会覆盖前值，且ReadInConfig()仍只读这一个文件
Sub() 是安全访问嵌套配置的唯一靠谱方式
viper.GetString("server.host") 看似简洁，但一旦 server 是 map 类型而实际配置里缺失或拼错字段，它就静默返回空字符串，不 panic 也不报错，线上出问题极难排查。真正可控的写法是分层获取子节点。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 先
srv := viper.Sub("server")，判断srv != nil再继续；否则说明顶层 key 不存在，该报错就报错 - 再用
srv.GetString("host")、srv.GetInt("port")，这时类型方法才真正起作用——因为Sub()返回的是新*Viper实例，自带上下文隔离 - YAML 里写
timeout: 30，Go 里必须用GetInt()，不是GetInt32()或GetInt64()；viper 解析数字默认是float64，强制转 int 时会截断小数，但不会 panic - 如果配置里用了
true/false，别用GetBool()直接读——某些 YAML 解析器（尤其旧版）可能把True当字符串，建议统一用GetString()后比对
WatchConfig() 在容器/CI 环境大概率失效
viper.WatchConfig() 底层依赖 fsnotify，而这个库在 tmpfs、overlayfs、GitHub Actions runner 或 Docker 默认挂载模式下，常因 inotify 事件不可达而静默失败——进程不报错，但文件改了也不触发回调。
立即学习“go语言免费学习笔记（深入）”；
- Linux 容器里要确保挂载卷不是
tmpfs，且内核支持 inotify（检查/proc/sys/fs/inotify/max_user_watches是否足够） - CI/CD 场景（如 GitHub Actions）中，
WatchConfig()基本不可用，应降级为启动时一次性加载 + 重启生效 - 即使监听成功，
OnConfigChange回调里重建 DB 连接、重置 logger 等操作，必须自己写完整初始化逻辑——Viper 不帮你 reload 业务状态 - 多次初始化（如单元测试里反复调
WatchConfig()）会导致 goroutine 泄漏，因为旧监听器没提供Stop()接口；生产代码里应确保全局只 init 一次
最麻烦的点不在语法，而在团队协作：没人约束 configs/base/config.yaml 和 configs/prod/config.yaml 的字段一致性时，Sub("redis").GetString("addr") 在 prod 环境跑着跑着突然返回空，你得翻三份 YAML 才发现 base 里写了 addr，prod 里删了它却没补 default——这种隐性断裂，Viper 不报、不拦、不提示。
