Go网关热更新指不重启进程、不中断流量地动态更新路由规则、限流策略与鉴权逻辑，核心是解耦可变行为为数据驱动或插件机制，通过线程安全路由容器（如RWMutex保护的map）原子替换handler实例，并配合预置插件集或WASM加载实现运行时行为变更。
热更新在 Go 网关里到底指什么
不是重启进程，也不是用 fsnotify 监听配置文件改完就 reload 路由——那只是配置热更新。真正需要热更新的，是路由规则、限流策略、鉴权逻辑这些运行时行为。Go 本身不支持代码热替换，所以必须把“可变逻辑”从主程序中解耦出来，用数据驱动或插件机制代替硬编码。
用 http.ServeMux 做不了热更新，换 httprouter 或 gorilla/mux 也不行
原生 ServeMux 和主流第三方路由器都是初始化后注册固定 handler，内部用 map 存储路由表，但没有提供安全的并发更新接口。直接替换 http.DefaultServeMux 或重赋值 mux 实例会导致：
- 正在处理的请求 panic（handler 被 GC 或已失效）
- 新旧路由表切换瞬间出现 404 或错配
- 无法原子更新中间件链（比如某个路由突然少了 JWT 验证）
正确做法是自己维护一个线程安全的路由容器，比如：
type RouteTable struct {
mu sync.RWMutex
routes map[string]http.Handler // path → handler
}所有请求都经过统一入口 func (rt *RouteTable) ServeHTTP(w http.ResponseWriter, r *http.Request)，内部用 RWMutex 控制读写，写操作（如加载新配置）走 Lock()，读操作（每次请求）只用 RLock()。
配置变更如何触发 handler 重建而不中断流量
关键不是“重新注册”，而是“平滑替换 handler 实例”。假设你用 YAML 定义路由：
routes: - path: /api/user upstream: http://user-svc:8080 auth: jwt rate_limit: 100/s
解析后不应直接调用 router.Handle(..., NewReverseProxy(...))，而应封装成可重建的 handler 工厂：
- 每个路由对应一个
*routeConfig结构体，含上游地址、中间件开关等字段 - 每次配置变更，调用
buildHandler(cfg *routeConfig)生成全新http.Handler（含 reverse proxy + auth middleware + rate limiter） - 在
RouteTable的写锁内，用新 handler 替换旧 map entry，老 handler 自动被 GC - 已有请求继续用旧 handler，新请求立即命中新逻辑
注意：reverse proxy 的 Director 函数必须捕获当前配置快照（闭包捕获），不能引用外部可变变量，否则会出现上游地址错乱。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
插件式鉴权/限流逻辑怎么热加载
硬编码 if cfg.Auth == "jwt" { ... } 会导致每次加新鉴权方式就得发版。应该定义接口：
type AuthPlugin interface {
Authenticate(*http.Request) (bool, error)
}然后用 map 注册实现：
- 启动时预加载
map[string]AuthPlugin{"jwt": &JWTPlugin{}, "apikey": &APIKeyPlugin{}} - 配置里只写
auth: jwt，运行时通过字符串查表获取实例 - 新增插件只需编译成独立
.so文件（用 Go 1.21+ 的 plugin 包），再通过plugin.Open()加载并注册到 map —— 注意插件必须导出符号且 ABI 兼容 - 更稳妥的做法是用 WASM（如 Wazero）跑 Lua/JS 插件，避免 ABI 问题，但性能略低
真实项目里，多数团队选择“配置驱动 + 预置插件集合”，而不是真动态加载二进制，因为后者对部署、调试、安全审计都增加复杂度。
热更新最难的不是技术实现，而是状态一致性：比如限流器的计数器要不要继承？JWT 黑名单缓存要不要同步？这些没法靠一把锁解决，得根据业务容忍度做取舍——有些场景宁可丢几秒统计，也不能卡住 reload 流程。
