直接用viper读YAML/TOML有隐性开销：默认WatchConfig、自动环境变量绑定、多格式fallback查找会拖慢首次加载；应显式SetConfigType、SetConfigFile，禁用WatchConfig和AutomaticEnv；结构体字段必须首字母大写且加对应标签（如yaml:"port"），否则静默丢弃。
直接用 viper 读 YAML/TOML 文件，性能不差但有隐性开销
默认开启的 viper.WatchConfig()、自动环境变量绑定、多格式 fallback 查找（如同时查 config.yaml、config.yml、config.toml）会显著拖慢首次加载。如果你只需要单次、静态读取，必须显式关闭这些功能。
- 调用
v.SetConfigType("yaml")或v.SetConfigType("toml")，避免自动探测 - 用
v.SetConfigFile("./config.yaml")而非v.AddConfigPath("./config")+v.ReadInConfig()，跳过路径遍历和文件名匹配逻辑 - 禁用监听：
v.OnConfigChange(nil)，且不要调用v.WatchConfig() - 禁用环境变量覆盖：
v.AutomaticEnv()不要调用，或调用后立即v.SetEnvKeyReplacer(strings.NewReplacer(".", "_"))并确保没设相关环境变量
gopkg.in/yaml.v3 和 github.com/BurntSushi/toml 手动解析更轻量
当配置结构固定、无需运行时重载，绕过 viper 直接用底层库，能省掉约 30%~50% 的初始化耗时（实测 10KB 配置文件，viper 平均 1.2ms，纯 yaml.v3 约 0.7ms）。关键不是“快多少”，而是可控——没有隐藏行为。
- YAML：用
os.ReadFile()读字节，再传给yaml.Unmarshal()；别用ioutil.ReadFile()（已弃用） - TOML：同理，
toml.Decode()接收[]byte，不走文件句柄 - 两者都支持结构体标签：
yaml:"port"/toml:"port"，字段必须首字母大写，否则静默丢弃 - 若配置含动态 key（如按环境名分组），TOML 用
map[string]EnvConfig，YAML 用map[string]any+ 类型断言（注意 v3 返回的是map[string]any，不是map[string]interface{}）
结构体字段小写 = 配置失效，且不报错
这是最常踩的坑。Go 反射无法访问小写字段，yaml.Unmarshal 和 toml.Decode 都会跳过它们，赋零值（int 为 0，string 为空），而不会 panic 或 warn。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 错误写法：
Port int `yaml:"port"`✅ 正确（字段导出 + 标签映射小写键） - 错误写法：
port int `yaml:"port"`❌ 字段未导出，永远为 0 - 嵌套结构体同理：子结构体字段也必须首字母大写，哪怕顶层字段已导出
- YAML 键名大小写敏感：
yaml:"Port"只匹配Port: 8080，不匹配port: 8080
首次读取后缓存解析结果，别反复 Unmarshal
配置通常只在启动时读一次，但有人会在每次 HTTP 请求里调 viper.Get() 或重新 yaml.Unmarshal()。这毫无必要，且浪费 CPU。
立即学习“go语言免费学习笔记（深入）”；
- 把解析后的结构体指针存在包级变量或依赖注入容器里，全局复用
- 如果真需热更新，用
viper.WatchConfig()+v.OnConfigChange()，但注意它基于 fsnotify，Linux 下对 NFS 共享目录可能失效 - 避免在
Unmarshal过程中做默认值填充或字段计算——那属于业务逻辑，应在解析完成后统一处理，否则难以单元测试且耦合严重 - 大配置文件（>1MB）建议用
bufio.NewReader包装os.File，减少系统调用次数；但对多数微服务配置（os.ReadFile() 更简洁高效
Unmarshal 只负责字节到内存的忠实转换，后续逻辑就越可控。 
