Viper.ReadInConfig() 默认 panic 是因找不到配置文件时调用 log.Fatal，需提前设 viper.Set("errorOnMissingFile", true) 改为返回 error；关键配置应设默认值、用 IsSet 检查、显式 BindEnv 并注意大小写与分隔符；WatchConfig 需配合 OnConfigChange 且路径配置正确。
为什么 Viper.ReadInConfig() 会 panic 而不是返回 error？
因为默认情况下，Viper 在找不到配置文件时直接调用 log.Fatal，而不是把错误交给你处理。这不是 bug，是它早期设计的“强硬默认”——它假设你一定有配置文件。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 必须在
Viper.ReadInConfig()前调用viper.Set("errorOnMissingFile", true)，否则一旦文件不存在，进程就退出，根本没机会 fallback - 更稳妥的做法是先用
viper.ConfigFileUsed()判断是否已加载配置，或手动检查文件是否存在：os.Stat("config.yaml") - 别依赖
viper.Unmarshal()的 error 来捕获读取失败——它只管解析，不管文件找不找得到
如何让 viper.Get() 安全返回默认值而不 panic？
viper.Get() 本身不会 panic，但如果你用 viper.GetInt() 或 viper.GetString() 去取一个未定义且没设默认值的 key，它会返回零值（比如 0 或空字符串），而你可能误以为这是合法配置。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 所有关键配置项都显式设置默认值：
viper.SetDefault("server.port", 8080)，而不是靠类型转换兜底 - 用
viper.IsSet("db.url")主动检查 key 是否被真正加载（来自文件、环境变量或 set） - 避免链式调用如
viper.GetInt("timeout") * time.Second——如果timeout未设，默认是0，结果就是0s，容易埋雷
环境变量覆盖配置时，大小写和分隔符怎么对齐？
Viper 默认把 yaml 中的 api.timeout_ms 映射成环境变量 API_TIMEOUT_MS，但如果你导出的是 API_TIMEOUTMS 或 api_timeout_ms，它就匹配不上。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 调用
viper.SetEnvKeyReplacer(strings.NewReplacer(".", "_"))确保点号转下划线 - 必须在
viper.AutomaticEnv()之前设置，否则无效 - 环境变量名统一用大写 + 下划线，不要依赖系统 shell 的大小写行为（Linux 区分，Windows 不区分，K8s ConfigMap 总是大写）
- 用
viper.BindEnv("database.host", "DB_HOST")显式绑定，比自动推导更可控
热重载配置时，viper.WatchConfig() 为什么没反应？
常见现象：改了 config.yaml，控制台没打印日志，viper.Get() 还是旧值——大概率是没注册回调，或者文件路径没对上。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
-
viper.WatchConfig()必须配合viper.OnConfigChange()才生效，光调用前者没用 - 确保
viper.AddConfigPath()指向的是文件所在目录，不是文件全路径；viper.SetConfigFile()才设具体文件名 - 某些文件系统（如 Docker 挂载的 configmap、WSL2）不支持 inotify，watch 会静默失败，建议加 fallback 日志：
fmt.Printf("config changed: %+v\n", e) - 重载后记得重新校验关键字段，比如
viper.GetInt("log.level")可能变成非法值，需要你手动 reject
配置读取最麻烦的从来不是语法，而是“你以为它加载了，其实它用了零值”——尤其在 CI/CD 或容器启动时，文件路径、权限、环境变量注入顺序稍有偏差，viper 就会安静地用默认值跑下去，直到某个超时或连接被拒绝才暴露问题。
