直接报“config file not found”是因为viper默认仅在当前工作目录查找且不递归，必须显式调用AddConfigPath指定路径（如"./configs"）并配合SetConfigName和SetConfigType，否则无法定位配置文件。
为什么直接用 viper.ReadInConfig() 总报 “config file not found”
不是文件路径错了，就是工作目录没对上。Viper 默认只在当前进程启动目录下找配置文件，不自动递归或向上查找。你 go run main.go 时 pwd 是项目根目录，但如果你在子目录里执行，或者用 IDE 运行（比如 GoLand 默认工作目录可能是模块路径），viper.ReadInConfig() 就会找不到 config.yaml。
- 最稳的方式是显式设置搜索路径：
viper.AddConfigPath("./configs")或viper.AddConfigPath("../configs")，再调viper.ReadInConfig() - 如果配置文件和二进制在同一目录，用
viper.SetConfigFile("config.yaml")+viper.ReadInConfig()更可靠，它不依赖路径搜索逻辑 - 别信
viper.AutomaticEnv()能帮你绕过这个——它只影响环境变量映射，不解决文件定位问题
YAML 和 JSON 配置里嵌套结构怎么取值才不出 panic
Viper 的 viper.Get() 返回 interface{}，直接断言容易 panic；viper.GetString() 等类型方法又对嵌套字段无效。真正安全的写法是用 viper.Sub() 分层获取子对象，再用类型方法读取。
- 错误示范：
viper.GetString("database.host")—— 如果database是 map，这会返回空字符串，不报错但结果不对 - 正确做法：
db := viper.Sub("database"); if db != nil { host := db.GetString("host") } - 注意：YAML 中
true/false、数字、null 在 Go 里反序列化后类型可能和预期不同，比如timeout: 30读出来是float64，要用GetInt()而不是GetInt32()
多个配置源混用时，环境变量和文件谁优先级更高
Viper 的覆盖顺序是固定的：默认值 viper.BindEnv("log.level", "LOG_LEVEL") 后，只要设置了 LOG_LEVEL 环境变量，它就会覆盖 YAML 里的 log.level。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 常见陷阱：开发时本地跑没问题，一上 Docker 就行为异常——因为容器里设置了环境变量，悄悄覆盖了 config.yaml
- 调试技巧：用
viper.AllSettings()打印最终生效的全部配置，比逐个GetString()更直观 - 如果想让文件优先于环境变量，就别调
viper.BindEnv()，改用viper.SetDefault("log.level", "info")+ 文件加载，再手动从os.Getenv()覆盖关键项
热重载配置要小心 goroutine 泄漏和并发读写冲突
Viper 本身不提供热重载，viper.WatchConfig() 是基于 fsnotify 实现的，它内部启 goroutine 监听文件变化，但不会自动 stop。如果多次调用（比如测试中反复初始化），旧监听器还在跑，新监听器又起一个，就会累积 goroutine。
立即学习“go语言免费学习笔记（深入）”；
- 必须在程序退出前调用
viper.OnConfigChange(func(e fsnotify.Event) {})里注册回调，且确保只注册一次 - 配置变更后，不要直接修改全局变量或结构体字段，而应重新调用
viper.Unmarshal(&cfg)刷新整个结构体，避免部分字段未更新 - 所有读配置的地方，都应加锁或用
sync.Once初始化，否则高并发下可能读到中间态（比如一半字段已更新，一半还是旧值）
配置热重载不是加一行 viper.WatchConfig() 就完事，它把文件监听、反序列化、线程安全全扔给你自己兜底。
