viper需显式调用Unmarshal绑定配置到结构体，正确设置tag、路径、默认值，并避免全局状态污染测试。
用 viper 读取 YAML/JSON 配置并绑定到结构体
Go 没有内置配置解析库，viper 是最常用且稳定的方案。它能自动处理文件读取、格式解析、环境变量覆盖和热重载，但默认不直接绑定到自定义结构体——得调用 Unmarshal 或 Bind 才行。
常见错误是只调用 viper.ReadInConfig() 就以为配置已加载进结构体，结果字段全是零值。实际必须显式解码：
- 确保结构体字段有正确的
yaml或jsontag，比如Port int `yaml:"port"` - 调用
viper.Unmarshal(&cfg)，而不是依赖viper.Get("port")手动赋值 - 如果配置键名含下划线（如
db_user），结构体字段可用db_user string `yaml:"db_user"`，或启用viper.SetEnvKeyReplacer(strings.NewReplacer("_", "."))统一转为点号
viper 自动查找配置文件的路径逻辑
viper 默认在当前目录搜 config.yaml、config.yml、config.json 等，但不会递归向上找，也不会自动检查 $HOME/.app/ 或 /etc/app/。容易踩坑的是：本地开发时文件在根目录能跑，打包成 Docker 镜像后因工作目录变了就报 Config File "config" Not Found in "[.]"。
- 显式指定路径比依赖自动发现更可靠：
viper.AddConfigPath("/etc/myapp")、viper.AddConfigPath("$HOME/.myapp") -
viper.SetConfigName("config")和viper.SetConfigType("yaml")要在ReadInConfig()前调用 - 用
viper.Debug()可打印当前所有已加载的配置源（包括 env、flags、files），排查是否真读到了文件
结构体嵌套与默认值控制
嵌套结构体（如 Database struct { Host string `yaml:"host"` }）能正常绑定，但要注意字段名大小写和 tag 一致性。更麻烦的是默认值：YAML 文件里没写的字段，Go 结构体对应字段会是零值（""、0、false），而你可能期望它 fallback 到代码里的默认值。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 不要靠结构体字段初始化赋值（
Timeout int `yaml:"timeout"` = 30是非法语法） - 改用
viper.SetDefault("database.timeout", 30)在ReadInConfig()前设置 - 若需运行时动态计算默认值（如根据环境决定日志级别），先
viper.ReadInConfig()，再用viper.IsSet("log.level")判断是否显式配置，未设则手动赋值
避免 viper 全局状态导致的测试污染
viper 默认使用单例，单元测试中修改了它的配置，下一个测试可能拿到脏数据。尤其当你在 init() 里调用了 viper.AddConfigPath()，整个包测试都会受影响。
- 测试中用
viper.Reset()清空所有设置（包括 defaults、paths、overrides） - 更稳妥的做法是封装一层：定义自己的
Config类型，内部持有一个私有*viper.Viper实例，构造时调用viper.New()，而非用全局实例 - 别在
init()中触发配置加载；把LoadConfig()设为显式函数调用，方便测试时传入 mock 文件路径
配置绑定看着简单，但路径、tag、默认值、测试隔离这四块最容易漏掉一环就出问题。尤其是 viper 的“自动”行为，往往掩盖了配置没真正加载的事实。
