viper本身不支持多级环境目录，仅通过addconfigpath注册路径并手动拼接环境名模拟；需先readinconfig加载公共配置，再mergeinconfig合并环境配置实现覆盖。
直接说结论：Viper 本身不支持“多级环境目录”这种结构，它只认配置文件路径和名称；所谓多级目录，本质是靠 viper.AddConfigPath 多次注册 + 手动拼接环境名来模拟的。
为什么不能直接用 viper.AddConfigPath("config/prod") 加载 prod 目录？
Viper 的 AddConfigPath 只负责添加搜索路径，不会自动按目录名识别环境。它会在每个路径下依次查找 viper.SetConfigName 指定的文件名（如 config），再匹配 SetConfigType 类型（如 yaml）。如果你把 config.yaml 放在 config/prod/ 下，但没显式设置 SetConfigFile("config/prod/config.yaml")，Viper 就找不到它——它只搜 config/prod/config.yaml、config/prod/config.yml 等，但不会递归扫描子目录。
- 常见错误现象：
viper.ReadInConfig()报错Config File "config" Not Found in "[config]"，其实是路径没对上，不是文件不存在 - 正确做法是：用
viper.AddConfigPath("config")，然后靠启动参数决定加载哪个环境文件，比如config-prod.yaml - 如果硬要目录结构，得手动构造路径：
viper.SetConfigFile("config/prod/config.yaml")，此时AddConfigPath就失效了
viper.MergeInConfig() 和 viper.ReadInConfig() 怎么配合实现“公共 + 环境”覆盖？
这是最常用也最稳妥的多环境方案：先加载公共配置（application.yaml），再用 MergeInConfig() 合并环境专属配置（如 application-prod.yaml），后者字段会覆盖前者。
-
ReadInConfig()是首次加载，失败就 panic；MergeInConfig()是后续合并，失败仍可继续（但建议 panic） - 注意顺序：必须先
ReadInConfig()公共配置，再MergeInConfig()环境配置，反过来会丢掉公共字段 - 示例中常漏掉
viper.SetConfigType("yaml")—— 每次调用SetConfigFile后都得重设类型，否则可能解析失败 - 环境名从 flag 获取：
flag.StringVar(&env, "env", "dev", "environment: dev|sit|pro")，然后拼路径：fmt.Sprintf("config/application-%s.yaml", env)
如何避免 viper.AutomaticEnv() 干扰配置覆盖逻辑？
AutomaticEnv() 会让 Viper 自动把环境变量映射成配置键（如 APP_PORT → app.port），但它是在所有文件加载完之后才生效的，所以会“最终覆盖” YAML 里的值——这常导致线上配置被本地环境变量意外覆盖。
- 典型踩坑：本地
APP_MODE=dev，但部署时忘了清环境变量，结果生产服务跑在 dev 模式 - 解决方案：只在开发阶段启用
AutomaticEnv()，生产环境注释掉或用条件控制 - 更安全的做法：用
viper.BindEnv("app.mode", "APP_MODE")显式绑定关键字段，而不是全局启用 - 别依赖
viper.SetEnvPrefix()配合AutomaticEnv()—— 前缀容易和第三方库冲突（比如 Zap 日志也读ZAP_*）
真正麻烦的不是怎么写代码，而是配置文件的加载顺序和覆盖优先级——YAML 文件之间、文件与 flag 之间、文件与环境变量之间，哪一层能盖过哪一层，必须在每次 viper.Unmarshal 前心里有数。否则改了一个地方，线上行为却没变，十有八九是某层覆盖被你忽略了。
