viper.readinconfig()不会自动合并多个yaml文件，因其设计为“按名查找首个”，只加载首个匹配文件（如config.yaml），需手动调用mergeconfig()按base→env→local顺序叠加实现分层覆盖。
为什么 viper.ReadInConfig() 不会自动合并多个 YAML 文件
viper.ReadInConfig() 只扫描并加载第一个匹配的配置文件（如 config.yaml），哪怕目录里同时存在 config.prod.yaml、config.local.yaml，也完全不会读取其余文件。这不是 bug，是设计如此：viper 默认不递归、不叠加、不按命名约定自动识别多文件。
常见错误现象：viper.Get("database.host") 返回空，但你确实在 config.prod.yaml 里写了；或者 config.local.yaml 的覆盖项根本没生效——因为该文件压根没被加载。
- 必须手动调用
viper.MergeConfig()，顺序即优先级 -
MergeConfig是纯内存操作，不依赖路径，需先用os.ReadFile()读取内容再传入 - 每次调用都要检查
err，尤其os.ReadFile在文件不存在时会失败，不能假设它一定存在
如何用 viper.MergeConfig() 实现 base → env → local 分层覆盖
最常用且安全的三段式加载顺序是：基础配置 → 环境配置 → 本地覆盖。后一次 MergeConfig() 中同名 key 会覆盖前一次，嵌套结构（如 database）会递归合并，不是全量替换。
- 先加载
config.yaml：viper.MergeConfig(bytes1) - 再加载
config.$ENV.yaml（例如config.prod.yaml）：viper.MergeConfig(bytes2) - 最后加载
config.local.yaml（通常.gitignore掉）：viper.MergeConfig(bytes3)
注意：环境变量应作为最终覆盖层，优先级高于所有文件，不能靠 MergeConfig 加载——要用 viper.AutomaticEnv() 配合前缀规则（如 VIPER_DATABASE_HOST → database.host），而非手动解析 os.Environ() 后递归映射。
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
go-ini 怎么合并多个 INI 文件才不丢节数据
go-ini 本身不支持多文件自动合并，[database.mysql] 这类带点号的节名会被当作独立节处理，不会自动挂到 [database] 下。想让 config.dev.ini 中的 [database.mysql] 覆盖 config.base.ini 中的 [database] 字段，必须手动提取赋值，不能依赖 ReflectFrom() 自动嵌套。
- 用
ini.Empty()初始化底座，再按顺序Append()或ReflectFrom() -
ReflectFrom()是内存叠加，不会清空 base 中 env 未定义的字段 - 节名统一用
[database]而非[database.mysql]，靠环境变量或参数切换值，更可控 - 并发写同一 INI 文件极危险：
SaveTo()是全量重写，必须用sync.RWMutex保护写操作
大配置文件合并时最容易 OOM 的地方
别用 os.ReadFile() 加载几十 MB 以上的 YAML/INI，它会把整个文件读进内存，极易触发 GC 压力甚至 OOM。尤其当多个大配置文件叠加时，内存占用是累加的。
- 对超大配置文件，改用流式解析器（如
gopkg.in/yaml.v3的yaml.NewDecoder()）边读边解码 - 避免在
MergeConfig前做任何bytes.Buffer或strings.Builder拼接 - YAML 中深层嵌套或超长字符串（如内联证书 PEM）要提前评估内存开销
- 若配置项本身是动态生成的（如从 DB 或 API 拉取），优先考虑运行时注入，而非塞进文件合并流程
分层合并的关键不在“能不能”，而在“谁覆盖谁”——顺序错了，config.local.yaml 就可能被 config.prod.yaml 覆盖掉，而你查日志时还发现不了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
