热更新在Go微服务中分场景：配置需手动回调重载，路由与中间件须重建handler实例，二进制只能靠子进程接管；硬编码逻辑无法热更，强行反射或plugin易崩溃。
配置热更新：viper.WatchConfig() 不是开关，是事件通知器
viper.WatchConfig() 只发 fsnotify.Event，不解析也不重载——你得自己在回调里调 viper.ReadInConfig() 或 viper.Unmarshal()，否则配置永远卡在旧值。
-
viper.SetConfigType("yaml")必须在viper.ReadInConfig()之前调，否则反序列化失败 - 回调运行在独立 goroutine，更新全局结构体时必须加
sync.RWMutex或用atomic.Value替换指针 - 字段没生效？先检查 struct 字段是否导出（首字母大写）、
jsontag 是否拼错、大小写是否匹配 - 用
viper.AllSettings()覆盖 map 容易漏字段，推荐viper.Unmarshal(&cfg)全量重建结构体
远程配置中心（etcd/Consul/Apollo）：别依赖 viper.WatchConfig()
viper 默认只监听本地文件，对 etcd 或 Apollo 的变更完全无感。必须绕过 viper 的 watch 机制，直接用 SDK 的 watch 回调驱动更新。
- etcd：用
clientv3.Watch()监听 key 前缀，收到PUT事件后解析字节流，再调viper.ReadConfig(bytes.NewReader(data)) - Apollo：注册
WithOnChange()回调，遍历ChangeEvent.Changes，对每个key调viper.Set(key, value)—— 注意 key 格式要对齐（如db.host，不是db_host） - Consul KV：用
api.KV.Get()+api.KV.WatchPrefix()，避免单 key 监听漏变更 - 所有远程监听都建议起独立 goroutine，防止阻塞主流程
网关路由与中间件热更新：不能改 map，得换 handler 实例
原生 http.ServeMux 和主流第三方路由器（gorilla/mux、httprouter）都不支持并发安全的路由表更新。直接修改内部 map 会导致正在处理的请求 panic 或 404。
- 自己封装
RouteTable，用sync.RWMutex保护map[string]http.Handler - 每次配置变更，调用工厂函数
buildHandler(*routeConfig)生成全新http.Handler（含 reverse proxy、auth middleware、rate limiter） - 在写锁内原子替换 map entry；老 handler 自动被 GC，已有请求不受影响
-
Director函数必须闭包捕获当前配置快照，不能引用外部可变变量，否则上游地址会错乱
二进制热升级：不是 reload，是子进程接管 + fd 传递
Go 没有运行时模块加载能力。所谓“热更新二进制”，本质是启动新进程、复用旧 socket、等连接自然关闭后退出旧进程。
- 主进程监听
syscall.SIGUSR2（比SIGHUP更可控，systemd 不会误触发） - 收到信号后，检查新二进制是否存在且可执行（
os.Stat(newBinary); os.IsExecutable） - 调
listener.File()获取 fd，用exec.Command启动新进程，并通过ExtraFiles传入；同时用环境变量（如LISTEN_FD=3）显式传递 fd 编号 - 新进程用
net.FileListener(os.NewFile(uintptr(fd), ""))重建 listener - 旧进程需等待活跃连接超时或全部关闭后再退出，否则可能发 RST 中断连接
- 替换二进制文件必须用
os.Rename()原子操作，绝不能os.WriteFile()覆盖正在运行的文件
SetMaxOpenConns()，HTTP 客户端必须重建实例并原子替换引用——这些动作都得你手动触发，且多数需要锁或 atomic 协调。最容易被忽略的，是把“配置变了”和“行为变了”当成一回事。 
