viper.ReadInConfig() 不读环境变量，因仅加载文件；需在调用前设 AutomaticEnv() 和 SetEnvPrefix()。多环境配置须手动控制 SetConfigName()，Sub() 子实例不继承环境变量绑定，WatchConfig() 必须在 ReadInConfig() 成功后立即调用。
为什么 viper.ReadInConfig() 读不到环境变量值？
因为 viper.ReadInConfig() 只负责加载配置文件，不触碰环境变量或命令行参数。环境变量要靠 viper.AutomaticEnv() 或 viper.BindEnv() 显式启用，且必须在 ReadInConfig() 之前调用才生效。
常见错误是把 AutomaticEnv() 放在 ReadInConfig() 后面，导致环境变量完全没注册进 Viper 的合并流程。Viper 的优先级链（命令行 > 环境变量 > 文件 > 默认值）只在“获取值时”起作用，但前提是那些源已被提前声明。
-
viper.SetEnvPrefix("APP")必须设，否则AutomaticEnv()不知道该找APP_*还是MYAPP_* - 若用
BindEnv("server.port", "APP_SERVER_PORT")，第二个参数是真实环境变量名，大小写必须完全匹配 - 环境变量值类型不会自动转换：设置
APP_SERVER_PORT=8080后，viper.GetInt("server.port")才能正确解析；如果设成"8080"（带引号），会返回 0
如何让 viper 同时支持 config.yaml 和 config.prod.yaml 并按需加载？
别依赖 Viper 自动猜环境——它不干这事。你需要手动控制搜索路径和文件名，再配合环境变量或命令行参数决定加载哪个。
典型做法是：用 viper.SetConfigName() 动态设为 "config." + env，再确保对应路径下存在该文件。例如：
立即学习“go语言免费学习笔记（深入）”；
viper.AddConfigPath(".") // 当前目录
viper.AddConfigPath("/etc/myapp/") // 系统级路径
viper.SetConfigType("yaml")
<p>env := os.Getenv("APP_ENV")
if env == "" {
env = "dev"
}
viper.SetConfigName("config." + env) // 加载 config.prod.yaml 而非 config.yaml</p><p>if err := viper.ReadInConfig(); err != nil {
// fallback 到通用 config.yaml
viper.SetConfigName("config")
if fallbackErr := viper.ReadInConfig(); fallbackErr != nil {
panic(fallbackErr)
}
}
- 不要指望
viper.SetConfigName("config")自动尝试config.dev.yaml—— 它只认你指定的精确文件名 -
AddConfigPath()可调多次，Viper 按添加顺序从前往后搜索，找到第一个就停，不会合并多个同名文件 - 若需“叠加”不同环境的配置（如 base.yaml + prod.yaml），得手动用两个
viper.New()实例分别读取，再用Unmarshal()合并结构体
使用 viper.Sub("database") 后，子实例还能读环境变量吗？
不能。子实例（viper.Sub() 返回值）是主实例的视图，只继承已加载的键值快照，不继承环境变量绑定、远程配置、监听器等运行时行为。
也就是说：dbViper := rootViper.Sub("database") 只能访问 rootViper 中已解析出的 database.* 字段，对 APP_DATABASE_URL 这类环境变量完全无感。
- 如果需要子模块也支持环境变量覆盖，必须单独为子实例调用
SetEnvPrefix()和AutomaticEnv() - 更稳妥的做法是：不用
Sub()，而是用结构体绑定 +viper.UnmarshalKey("database", &dbCfg)，这样既隔离又保留类型安全 -
Sub()适合只读场景（如日志模块取log.level），不适合需要动态重载或跨源合并的模块
热更新配置时，viper.WatchConfig() 为什么没触发 OnConfigChange？
最常见原因是：你在调用 viper.WatchConfig() 前，没有先成功执行过 viper.ReadInConfig()。Watch 机制依赖底层 fsnotify 监听实际被读取的文件路径，而这个路径只在首次 ReadInConfig() 成功后才确定。
另一个隐蔽问题是：某些 IDE 或编辑器（如 VS Code 的保存策略）默认用“写入临时文件 + 原子替换”方式保存，这会导致 fsnotify 失去对原文件的监听。可改用 viper.SetConfigFile("/absolute/path/to/config.yaml") 显式指定绝对路径，避免路径歧义。
-
WatchConfig()必须在ReadInConfig()成功后立即调用，中间不能有SetConfigName()等修改配置源的操作 - 回调函数里不能直接调用
viper.GetXXX()—— 因为变更尚未应用，应改用传入的fsnotify.Event参数做轻量判断，或在回调末尾加time.Sleep(10 * time.Millisecond)再读 - Windows 下对符号链接或网络盘监听不稳定，生产环境建议用轮询模式（需自行实现
time.Ticker+viper.ReadInConfig()）
配置合并不是“读完就完”，关键在各源注册时机与作用域边界。环境变量要提前绑，子实例不继承运行时能力，热更新依赖首次加载的真实路径——这些点漏掉一个，整套机制就静默失效。
