最稳妥做法是用 viper 读取 YAML 配置：命名 config.yaml 放根目录，显式设置路径与名称，ReadInConfig 后必须检查错误；环境配置通过 SetDefault("env", "dev") + 动态拼接文件名 + MergeInConfig 实现；优先用字段名匹配（如 redis_url → RedisUrl），必要时用 mapstructure tag；禁用 AutomaticEnv()，改用 BindEnv() 显式绑定；开发可热重载，生产务必重启生效。
用 viper 读取 YAML 配置文件最稳妥
Go 原生 flag 和 os.Getenv 只适合极简场景，初级项目一上手就该用 viper。它支持多格式、多源、自动重载，且社区成熟度高，踩坑成本低。
常见错误是直接用 json.Unmarshal 读配置——一旦字段名拼错或类型不匹配，运行时报 panic: interface conversion，还难定位。而 viper 提供 GetString/GetInt 等安全访问方法，未定义键返回零值，不会崩。
实操建议：
- 把配置文件命名为
config.yaml放在项目根目录，避免路径硬编码； - 调用
viper.SetConfigName("config")+viper.AddConfigPath(".")显式指定位置； - 务必在
viper.ReadInConfig()后检查错误：if err := viper.ReadInConfig(); err != nil { log.Fatal("读取配置失败:", err) } - 不要依赖
viper.AutomaticEnv()自动映射环境变量——它会把DB_HOST映射成dbhost（下划线被忽略），容易和配置项冲突。
区分开发/生产环境的配置加载逻辑
初级项目常把所有配置写死在一份 YAML 里，靠注释开关切换环境，结果部署时漏改某行就炸。正确做法是让 viper 自动识别环境并合并配置。
立即学习“go语言免费学习笔记（深入）”；
使用场景：本地调试用 config.dev.yaml，线上用 config.prod.yaml，共用基础字段，差异项覆盖。
实操建议：
- 通过
viper.SetDefault("env", "dev")设默认环境； - 用
viper.GetString("env")动态拼接配置名：viper.SetConfigName("config." + env)； - 先
ReadInConfig()加载主配置，再viper.MergeInConfig()合并环境特有配置； - 环境变量优先级必须高于文件：调用
viper.BindEnv("db.port", "DB_PORT")，再用viper.GetInt("db.port")即可被DB_PORT=5433覆盖。
结构体绑定要避开字段标签陷阱
很多人用 viper.Unmarshal(&cfg) 绑定结构体，但字段名大小写或 tag 写错，会导致字段始终为零值，又没报错，排查极耗时。
关键点在于 Go 结构体字段必须首字母大写（导出），且 viper 默认按字段名（非 tag）匹配 YAML 键。例如 YAML 中是 redis_url，结构体字段写成 RedisUrl string 就能对上；若加了 yaml:"redis_url" 标签，反而要确保 tag 值完全一致。
实操建议：
- 结构体字段命名尽量与 YAML 键保持蛇形转驼峰（
log_level → LogLevel），减少 tag 依赖； - 如果必须用 tag，统一用
viper支持的mapstructure标签：Port int `mapstructure:"port"`； - 绑定后立刻校验关键字段：
if cfg.DB.Host == "" { log.Fatal("DB.Host 未配置") } - 避免嵌套过深的结构体——
viper对嵌套 map 的支持不如扁平键稳定。
热重载只在开发阶段开启，别上生产
viper.WatchConfig() 很诱人，但初级项目常误以为“上线也能自动刷新数据库地址”。实际上，配置变更可能涉及连接池重建、日志级别切换等副作用，没有业务层协同，极易引发状态不一致。
性能影响：监听文件会起 goroutine + 定期 stat，虽轻量，但生产环境没必要；兼容性风险：某些容器平台（如 Kubernetes）挂载的 ConfigMap 是只读文件系统，fsnotify 可能失效或报 no space left on device。
实操建议：
- 仅在
env == "dev"时调用viper.WatchConfig()； - 注册回调函数里不做阻塞操作，只打日志或设标志位，后续请求再按需 reload 逻辑；
- 生产环境一律重启进程生效配置——配合 Kubernetes 的
livenessProbe或 systemd 的 restart 策略更可控。
最易被忽略的是：YAML 文件里的注释缩进不规范（比如用 tab 混合空格）会导
致 viper 解析失败，报错信息却只显示 failed to unmarshal config，没提具体哪一行。建议用 yamllint 预检配置文件。
