viper.watchconfig() 本身不解析配置，需配合 setconfigtype、readinconfig 和 onconfigchange 才能生效；监听前必须确保文件存在且格式正确，嵌套结构需显式 unmarshal，运行时配置更新应通过 atomic.value 安全替换，并用 sync.once + channel 确保 http 服务启动前配置已就绪。
直接用 viper.WatchConfig() 不会自动生效，必须配 viper.SetConfigType()、viper.ReadInConfig() 和 viper.OnConfigChange() 三者协同，否则监听到变化也读不出新值。
为什么 viper.WatchConfig() 调了没反应
常见错误是只调 viper.WatchConfig() 却没注册回调或没设格式。Watch 本身不解析内容，只发通知；viper.OnConfigChange() 才是真正干活的入口，且必须在 viper.ReadInConfig() 成功之后注册。
-
viper.SetConfigType("yaml")必须在viper.ReadInConfig()前调用，否则首次变更时viper.Unmarshal()会报Unsupported Config Type "" - 路径必须指向具体文件：
viper.SetConfigFile("./config.yaml")，不能写成目录"./config"，否则 fsnotify 收到大量临时文件事件（如config.yaml~） - 监听前确保配置文件存在且可读，
viper.ReadInConfig()失败会导致后续 Watch 完全静默
嵌套结构体更新必须显式 viper.Unmarshal()
viper.WatchConfig() 默认只刷新顶层键值，对 database.connections[0].timeout 这类嵌套字段不会自动同步——旧 map/slice 的底层数组可能被复用，导致字段残留或 panic。
Colly 是一个用于 Go 语言的快速开源爬取和爬虫框架。它适用于从简单的页面提取到异步爬虫处理大量页面集合，支持请求回调和结构化解析。
- 回调中必须用
viper.Unmarshal(&cfg)（cfg是指针），不能只靠viper.Get()读单个字段 - 结构体字段需带正确 tag，例如
yaml:"timeout"，否则反序列化失败 - 每次更新都应
new(Config)创建全新实例，避免原地修改引发并发读写冲突
如何安全替换运行时配置对象
全局变量直接赋值（如 globalCfg = newCfg）在多 goroutine 场景下必然竞态。atomic.Value 是更轻量且无锁的选择，但类型断言容易漏写。
- 用
atomic.Value存储*Config指针，写入前new(Config)，读取时统一走GetConfig()函数做.(*Config)断言 - 业务代码禁止缓存
viper.GetXXX()返回值，所有读取必须经由GetConfig()，否则永远看不到新值 - 日志里打上配置版本标识，比如
os.Stat(configFile).ModTime().Unix()，方便确认是否真刷新了
HTTP 服务启动时怎么等配置就绪
viper.WatchConfig() 是异步启动监听协程，viper.ReadInConfig() 成功只代表初始加载完成，不代表监听已 ready。硬 sleep 或检查 viper.WatchConfig() 返回值都没用。
- 启动时用
sync.Once+ channel 实现“首次加载完成”信号，HTTP server 启动前select { case - 不要在
viper.OnConfigChange()回调里做阻塞操作（如 HTTP 请求、DB 查询），否则会丢事件；建议发消息到 channel，另起 goroutine 处理 - 配置中心（如 etcd）场景下，
viper.ReadRemoteConfig()必须成功后再调viper.WatchRemoteConfig()，否则监听无效
最常被忽略的是：配置变了，DB 连接池、HTTP client、定时器这些资源不会自动重建。你得在回调里显式调 db.SetMaxOpenConns() 或新建 http.Client 并原子替换引用——viper 不管这部分。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
