viper是go配置管理首选，因其支持环境变量覆盖、命令行优先级、多格式混用、热重载、类型校验等；手写解析器仅适合练手；需正确使用setconfigname、bindpflag、unmarshal+mapstructure tag及watchconfig回调重解析。
Go 语言写配置管理工具，核心不是“读文件”，而是“在运行时安全、可扩展、可覆盖地解析并提供结构化访问”——直接用 viper 是最现实的选择，自己手撸解析器只适合练手或极端受限场景。
为什么别急着自己写 yaml.Unmarshal + os.ReadFile 链路
看似简单的一次读取，实际要面对：环境变量覆盖、命令行参数优先级、多格式混用（config.yaml + .env）、热重载、类型校验、缺失字段默认值、敏感字段屏蔽（如密码）等。自己拼凑容易漏掉 viper.AutomaticEnv() 这类关键能力，后期维护成本远超预期。
- 硬编码路径导致测试难——应统一走
viper.AddConfigPath - 没设
viper.SetDefault("timeout", 30)，上线后因字段缺失 panic - 环境变量名和 YAML key 大小写不一致（如
DB_HOSTvsdb_host），viper默认不自动映射，需手动viper.SetEnvKeyReplacer(strings.NewReplacer(".", "_")) - 用
viper.ReadInConfig()前忘了viper.SetConfigName("config")和viper.SetConfigType("yaml")，报错Config File "config" Not Found in "[.]"
如何让 viper 支持多环境 + 命令行覆盖
典型需求是：开发用 config.dev.yaml，生产用 config.prod.yaml，但允许 --port 8081 临时覆盖端口。关键在加载顺序和命名约定：
- 调用
viper.SetConfigName(fmt.Sprintf("config.%s", env))动态设文件名 - 按优先级顺序调用：
viper.BindPFlag("port", rootCmd.Flags().Lookup("port"))（绑定 cobra flag）→viper.ReadInConfig()→viper.AutomaticEnv() - 环境变量前缀必须统一，例如
viper.SetEnvPrefix("myapp")，这样MYAPP_PORT=8082才能映射到port字段 - 避免在
init()里就调用viper.ReadInConfig()，否则单元测试无法注入 mock 配置
如何安全读取结构体配置（不是用 viper.Get 到处取）
直接 viper.GetString("db.host") 写满代码，等于把配置 schema 散落在各处，改字段名就得全局搜。正确做法是定义结构体 + viper.Unmarshal：
立即学习“go语言免费学习笔记（深入）”；
type Config struct {
DB struct {
Host string `mapstructure:"host"`
Port int `mapstructure:"port"`
Password string `mapstructure:"password" json:"-"` // 不序列化输出
} `mapstructure:"db"`
Timeout int `mapstructure:"timeout"`
}
var cfg Config
if err := viper.Unmarshal(&cfg); err != nil {
log.Fatal("failed to unmarshal config: ", err)
}
- 必须加
mapstructuretag，因为viper默认用这个库做反射映射（不是 JSON tag） - 字段首字母大写才可导出，小写字段（如
password）不会被Unmarshal覆盖 - 若配置文件中
db.port是字符串"5432"，而结构体定义为int，viper会自动转换；但若值为"abc"，则Unmarshal报错
热重载配置的坑：别只监听文件，要重置内部状态
用 viper.WatchConfig() 后，很多人以为配置自动更新了，其实只是重新读了文件——如果之前已用 viper.Unmarshal(&cfg) 解析过一次，cfg 变量本身不会变。
- 必须在
viper.OnConfigChange回调里重新调用viper.Unmarshal(&cfg) - 注意并发：多个 goroutine 同时读
cfg，而回调里在写，需加sync.RWMutex或用原子指针替换（atomic.StorePointer） - 某些字段（如数据库连接池）不能热更新，需在回调里触发 graceful shutdown + 重建，这部分逻辑不属于
viper职责
真正难的不是读配置，而是决定哪些该进配置、哪些该进代码、哪些该由服务发现提供。比如 Kubernetes 环境下，DB_HOST 更该来自 Service DNS，而不是 YAML 文件——工具再强，也救不了设计层面的错位。
