Viper最稳妥方案是动态设名而非硬编码：必须用viper.SetConfigName("config-"+os.Getenv("ENV"))并配合SetEnvKeyReplacer将server.port映射为SERVER_PORT，同时用MergeConfigFile合并基础配置，禁用WatchConfig，启动时打印配置快照验证。

用 Viper 是当前最稳妥的方案，硬编码文件名、手动 if 判断环境、在 init() 里加载配置，这三类做法在测试和部署时都会出问题。

为什么不能硬编码 config-prod.yaml

硬编码文件名会导致配置逻辑分散、CI/CD 流水线无法复用同一份二进制、本地测试容易漏掉分支。比如你写死 viper.SetConfigName("config-prod")，那测试时就得改代码才能跑 dev，一不小心就提交了生产配置。

• 必须用 viper.SetConfigName("config-" + os.Getenv("ENV")) 动态生成文件名，ENV 值由启动前注入（如 ENV=dev go run main.go）
• viper.AddConfigPath("./configs") 要固定调用一次，路径别拼接环境变量——否则 ./configs/dev 这种结构会让 Viper 找不到 config-dev.yaml
• 如果共用基础字段（如服务名、超时时间），单独建 config-base.yaml，用 viper.MergeConfigFile("./configs/config-base.yaml") 显式合并，且必须在 ReadInConfig() 之前调用

viper.AutomaticEnv() 读不到 server.port 的原因

调了 viper.AutomaticEnv() 却拿不到 viper.GetString("server.port")，不是 Viper 失效，而是它默认不解析点号层级——它会去找名为 SERVER.PORT 的环境变量，但系统里实际是 SERVER_PORT。

Golang Spf13 Viper

Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。

下载

• 必须加 viper.SetEnvKeyReplacer(strings.NewReplacer(".", "_"))，让 server.port → SERVER_PORT
• 同时设前缀：viper.SetEnvPrefix("app")，这样 app.server.port 就对应 APP_SERVER_PORT，避免和其他进程冲突
• 敏感字段（如 db.password）YAML 里必须留空或删掉，只从环境变量读；否则密钥可能误提交到 Git

配置加载失败的典型错误现象

常见报错是 Config File Not Found 或日志级别明明配了 info 却打出 debug，本质都是加载顺序或覆盖逻辑没理清。

立即学习“go语言免费学习笔记（深入）”；

• viper.ReadInConfig() 前必须先调 viper.SetConfigType("yaml")，否则扩展名缺失时会报 Unsupported Config Type ""
• 绝对不要多次调用 ReadInConfig() 加载不同文件——Viper 不支持“只读某一个”，重复调用会 merge，污染当前配置
• 结构体嵌套字段读不到？检查 mapstructure tag 是否逐层写对，比如 redis.host 对应字段得是 Host string `mapstructure:"host"`，而不是靠字段名自动匹配
• 生产环境禁用 viper.WatchConfig()，热重载在无状态服务里不仅没必要，还可能因文件权限或 NFS 延迟引发静默失败

真正难的不是怎么写，而是怎么确保每次启动都按预期加载：文件存在、环境变量生效、merge 顺序正确、敏感字段没泄露——这些全靠启动时打印最终生效的配置快照来验证，别信 ReadInConfig() == nil 就万事大吉。