应选 YAML 并显式配置类型；用结构体+mapstructure tag 统一解码并校验，禁用热重载，避免环境变量空值干扰查找顺序。
配置文件该用 JSON 还是 YAML？
Go 新手常纠结格式选型，其实关键不在“好看”，而在 viper 的默认行为和团队协作成本。JSON 语法严格、无注释、解析快；YAML 支持注释和嵌套缩进，适合人肉维护但容易因空格出错。如果你用 viper.SetConfigType("yaml") 却传入 .json 文件，viper.ReadInConfig() 会直接 panic：「Unsupported Config Type ""」——因为后缀没匹配上，viper 没法自动推断类型。
实操建议：
- 新手起步统一用
config.yaml，显式调用viper.SetConfigName("config"); viper.SetConfigType("yaml") - 把配置文件路径硬编码进
viper.AddConfigPath("./conf")，别依赖当前工作目录——go run main.go和./myapp的os.Getwd()可能不同 - 用
viper.AutomaticEnv()后，环境变量名要转成大写+下划线，比如db.port对应DB_PORT，否则不会覆盖
如何安全读取嵌套字段（比如 database.url）？
直接写 viper.GetString("database.url") 看似简单，但一旦 database 是 nil 或 url 字段缺失，返回空字符串，程序可能静默失败。更糟的是，如果配置里写成 URL（大小写不一致），Go 结构体绑定会失败，而 viper 不报错。
推荐做法：
- 定义结构体并用
viper.Unmarshal(&cfg)，而不是零散调用GetString——它会做字段存在性检查和类型转换 - 结构体字段必须加
mapstructuretag，例如：type Config struct { Database struct { URL string `mapstructure:"url"` Port int `mapstructure:"port"` } `mapstructure:"database"` } - 启动时加校验：
if err := viper.Unmarshal(&cfg); err != nil { log.Fatal(err) }，比运行中 panic 更早暴露问题
热重载配置真的需要吗？
多数 Go 项目不需要运行时 reload 配置。viper 的 viper.WatchConfig() 依赖 fsnotify，Windows 上有已知延迟，Linux 上对 NFS 挂载点支持差，且无法原子更新——旧配置刚被读取，新配置正在写入，中间状态可能让服务行为异常。
更稳的方案是：
- 把配置当成只读输入，进程启动时全量加载，出错就退出
- 需要变更时，用 systemd 或 k8s 的滚动更新机制重启服务，而非在进程内监听文件变化
- 真要热更新（如限流阈值），改用独立的
atomic.Value+ HTTP 接口推送，绕过文件系统
为什么 viper.Get("log.level") 返回 nil？
这不是 bug，而是 viper 的查找顺序导致：它先查环境变量 → 命令行参数 → 配置文件 → 默认值。如果 LOG_LEVEL 环境变量设为空字符串，viper 会认为该键“已设置”，不再往下找配置文件里的 log.level，最终 Get 返回 nil（不是空字符串）。
排查步骤：
- 打印
viper.AllKeys()看哪些键被实际加载了 - 用
viper.GetEnvKey("log.level")查看对应环境变量名，再echo $LOG_LEVEL确认是否为空 - 避免混用来源：要么全走配置文件，要么禁用环境变量——删掉
viper.AutomaticEnv()，或用viper.SetEnvPrefix("")关闭前缀映射
