signal.Notify 是热加载的起点，因其是唯一可靠跨平台方式让主 goroutine 感知 SIGHUP 等信号，必须在主 goroutine 中用带缓冲通道阻塞等待，且需配合并发安全的配置更新与失败回滚机制。
为什么 signal.Notify 是热加载的起点
Go 程序无法在不重启的情况下重读配置文件，除非你主动监听信号并触发重载逻辑。signal.Notify 是唯一可靠、跨平台的方式让主 goroutine 感知外部信号（如 SIGHUP），它不是“可选优化”，而是热加载的基础设施。别试图用文件监控或定时轮询替代——前者在容器环境常失效，后者引入延迟和竞态。
常见错误是把 signal.Notify 放在子 goroutine 里却不阻塞主 goroutine，导致程序直接退出；或者监听了 os.Interrupt（即 Ctrl+C）却误以为它等价于 SIGHUP（实际是 SIGINT）。
- 必须用
make(chan os.Signal, 1)创建带缓冲通道，否则首次信号可能丢失 - 只监听
syscall.SIGHUP，Linux/macOS 都支持；Windows 不支持该信号，需改用os.Kill或自定义 IPC 方式 - 主 goroutine 必须阻塞等待信号，例如
<-sigChan，不能让它跑完就 exit
配置重载必须解决并发安全问题
热加载本质是运行时替换全局配置变量，而 Go 中没有原子指针赋值（unsafe.Pointer 除外），直接赋值会导致读取方看到中间态——比如结构体字段部分更新、切片长度突变等。这不是理论风险，而是真实发生的 panic 或逻辑错乱。
典型场景：HTTP handler 正在读取 cfg.DBTimeout，此时热加载写入新配置，但只更新了 DBTimeout 字段，其他字段还是旧值。
立即学习“go语言免费学习笔记（深入）”；
- 用
sync.RWMutex包裹配置结构体读写，读多写少场景下性能足够 - 更推荐用不可变配置：每次重载都新建完整配置实例，用
atomic.StorePointer替换指针（需将配置转为*Config并用unsafe.Pointer转换） - 避免在重载函数里调用阻塞操作（如远程 API、数据库连接测试），否则信号响应卡住，多次
kill -HUP可能堆积
fsnotify 不能替代信号，但可作辅助触发源
有人想用 fsnotify 监控配置文件变更自动重载，这在开发机上看似方便，但在生产环境极不可靠：容器挂载卷可能不支持 inotify、NFS 共享目录事件丢失、权限限制导致监听失败。它只能作为本地调试的补充手段，绝不能作为热加载主路径。
如果你坚持加文件监听，注意两点：一是必须和信号路径共用同一套重载函数，避免逻辑分裂；二是监听器启动要晚于配置初始化，否则可能在首次读取前就收到 “create” 事件，触发空配置加载。
- 用
watcher.Add("config.yaml")后，立即触发一次手动重载，确保初始状态一致 - 对
fsnotify.Event的Op字段只响应fsnotify.Write，忽略Chmod和Rename（编辑器保存时常触发后者） - 务必用
defer watcher.Close()，否则 fd 泄露，尤其在频繁部署的 CI/CD 环境中会快速耗尽
重载失败时如何避免静默降级
配置文件语法错误、网络依赖不可达、校验失败……这些都会导致重载中途 panic 或返回错误。如果没处理，程序继续运行旧配置，运维人员却毫无感知——这是最危险的情况。
错误日志必须包含上下文：是信号触发还是文件触发？失败发生在解析阶段还是校验阶段？旧配置是否仍可用？
- 重载函数返回
error，并在外层用log.Printf("reload failed: %v", err)显式记录，不要吞掉 - 在重载前先做预校验：
newCfg.Validate()，失败则直接返回错误，不覆盖当前配置 - 关键服务（如数据库连接池）应在重载后执行轻量探测（如
db.PingContext(ctx)），失败则回滚到旧配置指针，并记录 “rollback due to health check failure”
真正难的不是监听信号或解析 YAML，而是让重载过程可观察、可中断、可回退。信号只是扳机，后面每一步都得有兜底。
