结构体字段必须导出（首字母大写），否则viper.unmarshal会静默失败，字段保持零值；嵌套结构、标签一致性、automaticenv调用顺序及优先使用get+类型断言而非全量unmarshal均为关键实践。
结构体字段必须导出，否则viper.Unmarshal会静默失败
viper.Unmarshal(&cfg) 依赖 Go 反射写入字段，而反射只能访问**导出字段（首字母大写）**。如果定义了 type Config struct { port int }，port 是小写，viper.Unmarshal 不会赋值，也不会报错——cfg.port 永远是零值。
- 正确写法：
Port int `json:"port"`或DBHost string `json:"db_host"` - 嵌套结构同理：子结构体字段也必须导出，如
Database struct { Host string `json:"host"` } - 标签名要与配置源一致：YAML 中是
log-level: debug，标签就得写LogLevel string `yaml:"log-level"`
别全量 Unmarshal，优先用 Get+类型断言定位问题
全量 viper.Unmarshal 容易掩盖哪一项解析失败，尤其当配置项多、嵌套深时，调试成本高。直接调用 viper.Get 系列方法更可控，失败时返回零值或可明确判断。
-
viper.GetInt("server.port")返回0，但你得自己判断是配置没设，还是设了非数字值 - 更安全的是
viper.GetInt64("server.port")，避免int在 32 位系统溢出 - 字符串用
viper.GetString("env")，布尔用viper.GetBool("debug")，它们都自动类型转换且失败不 panic - 若需校验必填项，建议显式检查：
if viper.GetString("db.host") == "" { return errors.New("db.host required") }
嵌套配置要用 Sub 分离，避免 mapstructure 依赖和类型推导陷阱
配置里有层级（如 database.host），直接 viper.Unmarshal 到结构体可能因字段名不匹配或类型嵌套不一致而失败。用 viper.Sub("database") 提前切片，再单独解包，更清晰可靠。
- 错误做法：
viper.Unmarshal(&cfg)同时映射顶层 + 嵌套字段，容易因标签缺失或大小写不一致漏赋值 - 推荐做法：
dbCfg := viper.Sub("database"); dbCfg.Unmarshal(&cfg.Database) - 如果嵌套结构含自定义类型（如
time.Duration），viper.Sub后仍需配合mapstructure.DecodeHook，但范围缩小，风险可控 - 注意：
viper.Sub("nonexistent")返回nil，调用前先if dbCfg != nil
AutomaticEnv 必须在 ReadInConfig 之前调用，否则环境变量不生效
这是最常踩的顺序坑。viper 的覆盖链是「命令行 > 环境变量 > 配置文件 > 默认值」，但环境变量要参与覆盖，必须提前启用 viper.AutomaticEnv()，否则它只读配置文件，完全忽略 ENV。
- 错误顺序：
viper.ReadInConfig()→viper.AutomaticEnv()→ 环境变量无效 - 正确顺序：
viper.SetConfigName("config")→viper.AddConfigPath("./conf")→viper.AutomaticEnv()→viper.ReadInConfig() - 若需显式绑定，用
viper.BindEnv("http.port", "HTTP_PORT")，它比AutomaticEnv优先级更高 - 环境变量名自动转小写+下划线（
DB_HOST→db.host），但结构体字段仍是大驼峰，靠标签对齐
server.port 在 config.yaml 里写成了 "8080"（字符串）、而代码期待 int 时，你得清楚这个转换发生在哪一层——viper 的 GetInt 会尝试转换，但 Unmarshal 会直接失败，且错误信息模糊。所以类型安全约束的本质，是选择控制点：要么在取值时强断言，要么在结构体定义时严守标签与导出规则。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
