Viper 初始化后读不到 config.yaml 是因默认只在当前工作目录查找，需显式设置路径；字段为空是因未用 mapstructure tag 匹配 YAML 键名；AutomaticEnv() 不生效是因环境变量名未按 DATABASE_HOST 规则命名；WatchConfig() 仅通知变更，不自动刷新已绑定值。
为什么 Viper 初始化后读不到 config.yaml 文件
常见现象是调用 viper.ReadInConfig() 报错 Config File "config" Not Found in "[.]"，本质是 Viper 没找到文件路径。它默认只在当前工作目录（os.Getwd() 返回的路径）下找，不自动向上递归或查 GOPATH。
- 显式指定配置路径：
viper.SetConfigFile("./configs/config.yaml")或viper.AddConfigPath("./configs")+viper.SetConfigName("config") - 确保路径存在且可读：用
os.Stat()提前检查，避免静默失败 - 注意 Go 运行时工作目录不等于项目根目录——用
go run main.go时，工作目录是main.go所在目录；用 IDE 运行可能被设为其他路径，建议打印os.Getwd()确认
viper.Unmarshal() 嵌套结构体字段为空怎么办
Viper 默认按 YAML 键名映射到 struct 字段，但大小写和 tag 不匹配就会跳过字段。比如 YAML 里写 db_port: 5432，而 struct 字段是 DBPort int 却没加 mapstructure:"db_port"，Viper 就不会赋值。
- 所有需要绑定的字段必须加
mapstructuretag，且值要和 YAML 键完全一致（包括下划线/短横） - 嵌套结构体也要逐层加 tag，不能只在外层 struct 加
- 切忌依赖首字母大写自动推导——YAML 是小写蛇形命名，Go 是大写驼峰，Viper 不做智能转换
- 示例：
viper.SetConfigName("app") viper.AddConfigPath(".") viper.ReadInConfig() type DBConfig struct { Host string `mapstructure:"db_host"` Port int `mapstructure:"db_port"` } type Config struct { DB DBConfig `mapstructure:"database"` }
环境变量覆盖配置时，viper.AutomaticEnv() 为啥不生效
启用 viper.AutomaticEnv() 后，仍读不到环境变量，通常是因为变量名和配置键对不上。Viper 默认把 . 和 - 替换成 _，再转成全大写去查环境变量，但不会反向推导嵌套结构。
- 例如
viper.GetString("database.host")会查环境变量DATABASE_HOST，不是DB_HOST或DATABASEHOST - 如果想用自定义前缀（如
MYAPP_DATABASE_HOST），得调用viper.SetEnvPrefix("MYAPP")，且必须在AutomaticEnv()之前调用 - 环境变量优先级高于配置文件，但低于
viper.Set()显式设置的值 - 调试技巧：运行前执行
env | grep MYAPP确认变量已导出，Go 中用os.Getenv()手动验证是否可见
热重载配置要不要用 viper.WatchConfig()
它能监听文件变化并触发回调，但不是“自动刷新所有已读值”，只是通知你“变了”。如果你在启动时已用 viper.Unmarshal() 把配置拷进 struct，那 struct 里的值不会自动更新。
立即学习“go语言免费学习笔记（深入）”；
- 真正需要热重载的场景，应把
viper.GetXXX()调用放在业务逻辑里（比如每次 HTTP 请求都取一次viper.GetInt("timeout")），而不是初始化时读一次存起来 -
WatchConfig()回调里适合做日志记录、连接重建等副作用操作，不适合用来重新Unmarshal()到全局变量——并发读写风险高 - 生产环境慎用：Linux 下基于 inotify，但容器中可能受限；Windows/macOS 行为不一致；小文件 OK，大配置文件频繁变更易触发性能抖动
