Go微服务热更新非代码重载，而是分层处理：配置需原子替换、路由须重建handler、二进制靠子进程接管；viper.WatchConfig仅通知，须手动ReadInConfig/Unmarshal并用atomic.Value安全切换，Fiber路由不可原地更新，必须重建app实例。
Go 用 Fiber 框架做热更新，不是“ reload 代码”，而是分层处理：配置可原子替换，路由必须重建 handler，二进制升级只能靠子进程接管。强行用 plugin 或反射热载逻辑，大概率 panic。
配置热更新：viper.WatchConfig() 只发通知，不自动生效
很多人以为调了 viper.WatchConfig() 就万事大吉，结果改完 YAML 文件，viper.GetString("db.host") 还是旧值——因为 Watch 只触发回调，不读新内容、不解析、不线程安全。
- 必须在回调里显式调
viper.ReadInConfig()或viper.Unmarshal(&cfg)，否则永远卡在首次加载的快照 -
viper.SetConfigType("yaml")必须在viper.ReadInConfig()前调，否则反序列化失败报Unsupported Config Type "" - 回调运行在独立 goroutine，若全局配置结构体被多个 HTTP handler 并发读取，得用
atomic.Value存指针（比sync.RWMutex更轻量） - 字段没生效？检查 struct 字段是否首字母大写（必须导出）、
jsontag 是否拼错、大小写是否和配置 key 完全一致（如log.level对应LogLevel string `json:"log.level"`）
Fiber 路由与中间件无法原地更新，必须重建 http.Handler
Fiber 的 app 实例内部路由表是初始化后就固定的，没有并发安全的 AddRoute 或 RemoveRoute 方法。直接改 app.routes（私有字段）或暴力重赋值，会导致正在处理的请求 panic 或 404。
- 封装一个
RouteManager，用sync.RWMutex保护当前http.Handler实例 - 每次配置变更，调用工厂函数（如
buildFiberApp(cfg *Config) *fiber.App）生成全新*fiber.App，再调app.Handler()得到新http.Handler - 在写锁内原子替换 handler 指针；老 handler 会随 GC 回收，已建立的连接不受影响
- 如果用了反向代理中间件（如
fiber.Proxy），Director函数必须闭包捕获当前配置快照，不能引用外部可变变量，否则上游地址可能错乱
二进制热升级：用子进程 + socket fd 传递，不是 in-process reload
Fiber 应用本身不支持“热替换二进制”，Go 程序一旦启动，代码段就固定在内存里。所谓“不停服升级”，本质是新旧进程交替——旧进程处理完存量连接后退出，新进程监听同一端口。
立即学习“go语言免费学习笔记（深入）”；
- 主进程收到
SIGHUP后，调syscall.Dup2()复制 listener fd，再用exec.Command启动新二进制，并把 fd 传给它 - 新进程通过
os.NewFile(uintptr(fd), "listener")恢复 listener，立即开始 accept 新连接 - 旧进程调
srv.Shutdown()等待活跃连接关闭（建议设ShutdownTimeout），然后退出 - 别依赖第三方库（如
graceful）自动处理，它们常忽略 fd 传递细节，导致新进程 bind 失败报address already in use
真正难的不是某一步怎么写，而是各层更新时机要对齐：配置变了，连接池得重建；路由变了，中间件链得重编译；二进制换了，老进程的 logger 实例还活着——这些对象生命周期不统一，最容易漏掉 cleanup 导致内存泄漏或状态错乱。
