go配置热加载需用fsnotify监听文件变更并原子替换配置指针：在goroutine中阻塞读events，仅响应write/chmod事件，配合sync.rwmutex或atomic.value安全切换，验证失败保留旧配置，并确保db池等组件真正生效。
为什么直接用 os.ReadFile 加 json.Unmarshal 不够用
因为配置变更时程序不会自动重载，硬重启又影响服务可用性。更麻烦的是，并发读写同一配置文件可能引发竞态——比如一个 goroutine 正在 os.WriteFile，另一个刚调用完 os.ReadFile，读到的就是半截内容。
- 必须加文件锁（
flock或进程内互斥），否则写入中途读取会得到损坏的 JSON - 不能每次读都打开文件，得缓存解析结果并监听变更，否则频繁
syscall.Stat拖慢性能 -
fsnotify的事件可能重复或丢失，需做去重 + fallback 定时轮询（比如 30s 一次）
用 fsnotify.Watcher 监听文件变更的正确姿势
别只监听单个文件路径，要监听整个目录，否则 mv new.conf old.conf && mv tmp.conf new.conf 这类原子替换会触发 Remove + Create，而你只监听了文件，Remove 后 Watcher 就失效了。
- 用
watcher.Add("/path/to/config/dir")，不是"/path/to/config.json" - 忽略
Chmod事件（编辑器常触发），只处理Write和Rename - 收到事件后，先
os.Stat确认文件存在且大小非零，再os.ReadFile，避免读到临时文件 - 解析失败时保留旧配置，打日志但不 panic，否则一次格式错误就让服务挂掉
配置结构体怎么设计才能支持热更新不崩
关键不是字段可变，而是引用不可变：所有运行时依赖配置的地方，必须通过指针访问当前生效的配置实例，而不是拷贝一份值。
- 定义全局变量
var Config *ConfigStruct，初始化为指针，热更新时原子替换指针（atomic.StorePointer或sync.RWMutex） - 结构体字段全部用指针（如
*string、*int）或不可变类型（time.Duration、map[string]string），避免深拷贝时漏掉嵌套字段 - 提供
GetDBTimeout() time.Duration这样的封装方法，内部加RLock，比直接暴露字段更安全
如何避免热更新时出现配置不一致的“中间态”
常见错误是先改字段再发通知，或者通知和赋值顺序错乱。比如 HTTP handler 正在读 Config.Timeout，另一 goroutine 却刚把新配置的 Timeout 写进去、还没写完 RetryLimit，这时读到的就是混合状态。
- 新配置必须完整解析成功后，才原子替换整个
*ConfigStruct指针 - 绝不允许逐字段赋值；哪怕只改一个字段，也要走完整 reload 流程
- 如果配置含切片（
[]string），确保底层数组不被旧 goroutine 缓存——用copy创建新底层数组，或改用sync.Map存储动态项
最易被忽略的是信号处理：SIGUSR1 触发 reload 时，若没设 signal.Ignore(syscall.SIGUSR1)，某些系统库可能捕获并终止进程。这个细节查日志都难定位，得提前埋好。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
