Viper 不会自动 fallback 多格式或识别非标准后缀，必须手动按顺序尝试文件并显式调用 viper.SetConfigType("yaml") 等且严格置于 ReadInConfig() 之前，否则报 unknown config type 或 Config File Not Found。
Viper 不会自动 fallback 多格式，也不会猜你用的是什么后缀——必须手动指定格式、手动按顺序尝试文件，否则不是报 unknown config type 就是 Config File Not Found。
为什么 viper.ReadInConfig() 总是失败或报 unknown config type
根本不是配置内容写错了，而是 Viper 根本没机会解析它。它只对极少数后缀硬编码识别：.json、.toml、.yaml、.yml、.properties、.env、.env.yaml。其余一概无视。
- 文件叫
config（无后缀）、app.conf、settings.txt→ 必须提前调viper.SetConfigType("yaml") - 用
embed.FS读字节流再喂给viper.ReadConfig(bytes.NewReader(data))→SetConfigType是唯一出路，SetConfigFile完全无效 - 类型名必须严格小写：
"json"可以，"JSON"会失败；"yaml"稳定，"yml"在部分版本里能蒙混但不保证 -
SetConfigType()必须在ReadInConfig()或ReadConfig()之前调用，且不能晚于SetConfigName()和AddConfigPath()
如何让 Go 应用同时支持 config.json 和 config.yaml 并按优先级加载
Viper 原生不支持“先找 A，找不到再找 B”。它的 ReadInConfig() 只走一次查找逻辑，依赖 SetConfigName() + AddConfigPath() 的组合，最终只加载第一个匹配项。
- 手动按顺序检查：
os.ReadFile("config.json")→ 成功就viper.SetConfigType("json")+viper.ReadConfig()；失败再试config.yaml - 别把路径硬编码进
AddConfigPath()后指望它自动扫多个后缀——它不会扫描，只拼path + "/" + name + "." + type - 若需运行时切换（比如测试用 JSON，生产用 YAML），把格式存进 flag：
flag.String("config-type", "yaml", "config file type")，然后viper.SetConfigType(*configTypeFlag)
viper.AddConfigPath() 在 embed.FS 下为何完全失效
AddConfigPath() 只操作本地文件系统（os.Open），对 embed.FS、io/fs.FS 或任何抽象文件系统零感知。直接调 ReadInConfig() 必然报 Config File Not Found。
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
立即学习“go语言免费学习笔记（深入）”；
- 正确做法：用
embed.FS读取后转*bytes.Reader，再喂给viper.ReadConfig() - 示例：
data, _ := assets.ReadFile("config.yaml")→viper.SetConfigType("yaml")→viper.ReadConfig(bytes.NewReader(data)) - 漏掉
SetConfigType()？照样报unknown config type，哪怕内容是合法 YAML
viper.WatchConfig() 为什么不触发或 panic
WatchConfig() 依赖 fsnotify，但默认只监听文件层级变化，不递归监听子目录；且若配置文件被编辑器“原子保存”（先写临时文件再 mv 覆盖），fsnotify 可能收到 CHMOD 或 MOVED_TO 事件而非变更通知。
- 必须在
ReadInConfig()之后调用，否则无效 - 监听路径必须是 Viper 实际加载的路径——如果用
SetConfigFile()指定了绝对路径，但WatchConfig()默认监听工作目录，容易监听错位置 - 容器内挂载卷（如
-v ./config.yaml:/app/config.yaml）时，inotify无法穿透 overlayfs，监听必然静默失败 - 回调里必须显式调
viper.ReadInConfig()或viper.Unmarshal(&cfg)，否则内存中值永远不变
最常被忽略的一点：所有 SetConfigType() 调用必须在 ReadInConfig() 或 ReadConfig() 之前，且不能晚于 SetConfigName() 和 AddConfigPath()；嵌入文件、无后缀、非标准后缀、多格式 fallback —— 这些都不是“配置格式问题”，而是 Viper 初始化流程的执行顺序问题。
