根本原因是工作目录与配置路径不匹配，需显式调用viper.AddConfigPath("config")；环境变量优先级高于文件，应通过SetEnvPrefix和SetEnvKeyReplacer实现自动映射；多文件配置需手动MergeConfigMap而非依赖ReadInConfig；热更新须在Watch回调中重新Unmarshal且字段必须导出；文件原子写入应使用os.Rename临时文件。
用 viper 加载多环境配置文件时，为什么 dev.yaml 总是不生效？
根本原因通常是工作目录和配置搜索路径没对齐，viper 默认只在当前目录找，而你把 config/dev.yaml 放在了子目录里却没显式设置路径。
- 必须调用
viper.AddConfigPath("config")，不能只靠viper.SetConfigName("dev") -
viper.SetConfigType("yaml")要在ReadInConfig()前调用，否则会报Unsupported Config Type "" - 环境变量覆盖优先级高于文件：如果设置了
APP_ENV=prod，即使你手动加载dev.yaml，viper.Get("server.port")仍可能返回 prod 的值——因为viper.AutomaticEnv()默认开启且优先级高
如何让 Go 服务启动时自动根据 APP_ENV 切换配置，又避免硬编码环境名？
靠 viper 的 SetEnvKeyReplacer + 约定命名规则，比 if-else 切 config 文件更可靠。
- 统一用
viper.SetEnvPrefix("app")，然后环境变量写成APP_SERVER_PORT=8081 - 调用
viper.SetEnvKeyReplacer(strings.NewReplacer(".", "_"))，这样viper.GetString("server.addr")就能映射到APP_SERVER_ADDR - 配置文件仍按环境分：
config/base.yaml（公共）+config/dev.yaml（覆盖），用viper.MergeConfigMap手动合并，别依赖ReadInConfig自动选——它不支持多文件叠加
配置热更新（如监听 etcd/ZooKeeper）时，为什么结构体字段没刷新？
viper.WatchConfig() 只触发回调，不会自动反序列化到已定义的 struct；常见错误是以为调一次 viper.Unmarshal(&cfg) 就万事大吉。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 必须在 Watch 回调里重新执行
viper.Unmarshal(&cfg)，且cfg要是地址（&cfg），不是值拷贝 - 如果用了嵌套结构体，确保所有字段都是导出的（首字母大写），否则
Unmarshal跳过它们 - etcd 场景下，
viper不直接支持 watch key prefix，得自己用clientv3.Watcher监听，再把变更内容喂给viper.ReadConfig(bytes.NewReader(data))
下发配置到多个微服务实例时，怎么避免某台机器读到半截 YAML？
本质是原子性问题：文件写入不是原子操作，os.Rename 是唯一靠谱方案，但很多人直接 os.WriteFile 覆盖原文件。
立即学习“go语言免费学习笔记（深入）”；
- 下发前先写临时文件：
config.yaml.tmp，校验 YAML 格式（用yaml.Unmarshal尝试解析）成功后再os.Rename("config.yaml.tmp", "config.yaml") - Go 侧读配置时，用
os.Stat检查文件修改时间是否变化，再触发重载——别依赖文件大小或简单轮询 - 如果用 Consul KV，注意它的
GET /v1/kv/config?recurse返回的是扁平 key 列表，需手动转成嵌套 map 再喂给viper.ReadConfig，否则viper.Get("db.host")会失败
配置热更新的边界很窄：watch 机制只管“有变更”，不管“变更是否合法”。YAML 缩进错一位、JSON 多个逗号，服务就可能 panic，这事得在下发端做语法校验，而不是指望运行时兜底。
