viper.readinconfig()仅加载第一个匹配文件，不自动合并多个；必须用mergeconfig显式叠加，按base→env→override顺序调用以实现分段加载与优先级控制。
Go 语言本身不提供配置自动合并能力，所谓“多源合并”完全取决于你用的库和加载顺序。没有银弹，只有明确控制。
为什么 viper.ReadInConfig() 不会自动合并多个文件
viper.ReadInConfig() 只读一个匹配的配置文件（按搜索路径+名称找第一个），不是“把所有 config.*.yaml 全部加载并合并”。它不会递归扫描目录、也不会叠加同级文件。
- 想合并多个 YAML 文件，必须显式调用多次
viper.MergeConfig()或viper.MergeConfigMap() - 比如先
viper.MergeConfig(file1)，再viper.MergeConfig(file2)，后者的同名 key 才会覆盖前者 - 如果只调一次
ReadInConfig()，哪怕目录里有config.yaml和config.local.yaml，也只会加载其中一个
用 viper.MergeConfig() 合并多个文件的正确姿势
手动控制加载顺序 = 控制优先级。环境变量和命令行参数虽有默认高优先级，但文件之间必须靠 MergeConfig 显式叠加。
- 先加载基础配置：
viper.MergeConfig(bytes1)（如config.yaml） - 再加载环境特化配置：
viper.MergeConfig(bytes2)（如config.prod.yaml） - 最后加载本地覆盖配置：
viper.MergeConfig(bytes3)（如config.local.yaml，常 gitignore） - 注意：所有
MergeConfig都是内存操作，不依赖文件路径；你需要自己用os.ReadFile读取内容再传入
koanf 的 Load() 顺序就是优先级，别写反
koanf 没有“默认优先级链”，它的合并行为完全由 Load() 调用顺序决定：后 Load() 的数据会递归合并进前一次结果，同名叶子值被覆盖，嵌套 map 会合并。
- 正确顺序：
k.Load(file.Provider("config.yaml"), yaml.Parser())→k.Load(env.Provider("APP_", "_", nil), nil)→k.Load(posflag.Provider(flags, ".", k), nil) - 常见错误：把
env.Provider放在最前面，结果环境变量被后面file.Provider冲掉 - 漏掉某一层（比如忘了加
env.Provider），k.String("db.host")就永远拿不到环境变量值，调试时很难定位
合并时 slice 不会追加，而是直接替换
几乎所有主流库（viper、koanf、go-spring）对 slice 类型都采用“全量替换”而非“元素追加”。这点极易误解。
- 若
config.yaml有features: ["a", "b"]，环境变量设APP_FEATURES=c,d，最终结果是["c", "d"]，不是["a","b","c","d"] - 没有标准库或通用方案支持自动追加 slice；如需此行为，必须在加载后手动处理，例如：
append(viper.GetStringSlice("features"), "c", "d") - map 类型则不同：嵌套结构如
server.timeout和server.port可共存，因为它们走的是递归合并逻辑
真正容易被忽略的是：合并逻辑不在配置格式里，而在你调用库的每一行代码中。少一次 MergeConfig，漏一个 Load()，或者把顺序写反，都会导致线上行为和预期不一致——而这种问题往往只在特定环境暴露，本地测不出。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
