viper.ReadInConfig() 找不到 config-dev.yaml 是因未动态设置配置名，须用 viper.SetConfigName("config-" + os.Getenv("ENV")) 并提前设 ENV=dev，且需调用 SetConfigType、AddConfigPath 等配套方法。
必须动态拼接 viper.SetConfigName，否则 viper.ReadInConfig() 根本不会去找 config-dev.yaml 这类文件——它只认你明确设的名字，不猜、不推、不 fallback。
为什么 viper.ReadInConfig() 找不到 config-dev.yaml
这不是文件路径错或权限问题，而是 viper 的加载逻辑根本没被触发去读那个文件。它默认只尝试 config.yaml（或你硬编码的固定名），不会根据 ENV=dev 自动补后缀。
- 错误写法：
viper.SetConfigName("config-prod")—— 一个字符串写死，换环境就报Config File Not Found - 正确写法：
viper.SetConfigName("config-" + os.Getenv("ENV"))，且确保启动前已设好ENV=dev（推荐小写） -
viper.AddConfigPath("./configs")的路径必须真实存在、可读；Docker 中挂载 ConfigMap 后，os.Stat可能成功但viper.ReadInConfig()静默失败——重点查文件权限和挂载是否为只读 - 必须在
viper.ReadInConfig()前调用viper.SetConfigType("yaml")，否则扩展名缺失或类型未注册会报Unsupported Config Type ""
viper.AutomaticEnv() 不自动处理点号层级
viper.AutomaticEnv() 默认只做全字符串匹配：配置项 server.port 会去找名为 SERVER_PORT 的环境变量，而不是 SERVER.PORT。系统里实际是 SERVER_PORT，但没做转换就永远读不到。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 尽早调
viper.SetEnvKeyReplacer(strings.NewReplacer(".", "_"))，让点号转下划线 - 加前缀避免冲突：
viper.SetEnvPrefix("app")，这样app.server.port对应APP_SERVER_PORT - 特殊映射（如
PGHOST→db.host）用viper.BindEnv("db.host", "PGHOST")显式绑定 - 别用
os.Getenv("SERVER_PORT")手动读——绕过了 viper 的优先级链（flag > env > file > default），也失去了 fallback 能力
嵌套结构体 Unmarshal 后字段为空
viper 不会推导字段名，也不自动转换命名风格（驼峰/下划线/点号）。它只严格匹配结构体上的 yaml:"xxx" tag，大小写敏感、一字不差。
- 字段没加
yamltag？必然为空 - tag 名写成
yaml:"server_port"，但配置里是server.port？不匹配，为空 - 配置里是
db-host，tag 写yaml:"db_host"？不匹配，为空 - 嵌套结构体要逐层打 tag，比如
type Config struct { Server ServerConfig `yaml:"server"` }，不能只给最内层字段打
最容易被忽略的是：viper 的 ReadInConfig() 是一次性动作，不是“监听文件变化”。生产环境禁用 WatchConfig()，热重载可能引发 panic 或配置状态不一致——上线前务必确认是否关闭。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
