不能直接在main.go中var Config *config.Config = &config.Config{...}，因为会导致配置不可验证、无法覆盖、测试难mock、业务逻辑与初始化耦合，且字段未初始化或类型错配仅在运行时暴露，易引发线上静默降级；正确做法是结构体绑定+显式校验+环境驱动加载，在main()开头就panic而非请求时崩。
为什么不能直接在 main.go 里 var Config *config.Config = &config.Config{...}
这样写看似简单，但会导致配置不可验证、无法覆盖、测试难 mock，且业务逻辑和初始化耦合。更严重的是，如果 config 结构体字段没初始化或类型错配，运行时才暴露（比如 timeout 字段为 0 却没报错），线上服务可能静默降级。
真正该做的是：用结构体绑定 + 显式校验 + 环境驱动加载，让配置在 main() 开头就 panic 在缺失字段或类型不匹配时，而不是等请求进来才崩。
-
viper.UnmarshalExact替代viper.Unmarshal，它会在字段名不匹配、tag 错误、类型不兼容时直接 panic - 所有嵌套字段必须显式加
mapstructuretag，哪怕字段名和 key 完全一致，例如Port int `mapstructure:"port"` - 连字符键名（如
max-connections）必须严格按配置文件写法匹配 tag，viper 不自动转驼峰或下划线
如何让 config-dev.yaml 和 config-prod.yaml 不互相污染
viper 的 ReadInConfig() 是“替换式”加载，不是 merge。如果你手动调两次 ReadInConfig()，后读的会完全覆盖前读的——dev 配置里的 debug: true 可能意外出现在 prod 启动日志里。
正确做法是靠环境变量驱动单次加载，不拼接、不合并、不 fallback。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 在
main()最开头只读一次os.Getenv("GO_ENV")，比如值为"prod" - 然后
viper.SetConfigName("config-" + env)，再viper.AddConfigPath("./configs")，最后viper.ReadInConfig() - 文件路径固定为
./configs/config-dev.yaml、./configs/config-prod.yaml，不建config.common.yaml试图“复用” - 若真需共享基础项（如日志级别），用
viper.MergeConfigFile("./configs/config-base.yaml")显式合并，且必须在ReadInConfig()之前调用
环境变量怎么才能被 viper 读到
viper.GetString("db.host") 返回空？不是配置文件漏写了，而是根本没启用环境变量绑定。viper 默认忽略所有系统环境变量，必须显式打开开关。
而且点号层级（db.host）默认映射不到 DB_HOST，因为 AutomaticEnv() 只按字符串匹配，不会把点转下划线。
- 必须在
viper.ReadInConfig()之前调用viper.AutomaticEnv() - 加
viper.SetEnvKeyReplacer(strings.NewReplacer(".", "_"))，否则server.port永远拿不到SERVER_PORT - 特殊映射用
viper.BindEnv("cache.url", "REDIS_URL")，比依赖命名规则更可靠 - 不要在中间件或 handler 里反复调
viper.Get*——配置应只在启动时解析一次，之后用结构体字段访问
全局变量该不该导出？怎么避免 init() 隐式初始化
很多人在 config 包里写 var Conf *Config，再在 init() 里加载，看似“自动”，实则破坏可测试性：单元测试无法控制加载时机，也无法注入 mock 配置。
导出本身没问题，但初始化必须显式、可控、可跳过。
- 声明导出变量
var Conf *Config是 OK 的，其他包可通过config.Conf.Port访问 - 但初始化函数要单独暴露，比如
func Load() error，由main()主动调用 - 绝不把
viper初始化、文件读取、校验逻辑塞进init()——那会让包导入即执行，IDE 跳转失效，测试难隔离 - 如果多个包都依赖配置，考虑用依赖注入（如传入
*Config参数），而非硬编码引用config.Conf
AutomaticEnv() 放错位置、多调一次 ReadInConfig()，都可能让问题延迟到上线后才浮现。 
