Go标准库net/http的ServeMux不支持运行时增删路由，因其Handle方法非并发安全且无删除接口；需用自定义Handler或chi等第三方路由器配合sync.RWMutex实现热更。
Go 标准库 net/http 本身不支持动态添加或删除路由，必须在服务启动前注册完毕；真要实现「运行时增删路由」，得自己封装路由表 + 用 http.ServeMux 或第三方路由器（如 gorilla/mux、chi）配合可变数据结构。
为什么 http.ServeMux 不能直接动态注册
http.ServeMux 的 Handle 和 HandleFunc 方法内部会修改私有字段 mu（读写锁）和 m（map），但它的 Handler 方法是线程安全的——而 Handle 不是并发安全的，且没有提供「删除」接口。直接并发调用 Handle 可能 panic 或漏注册。
- 错误现象：
fatal error: concurrent map writes或某次Handle调用后新路由完全不生效 - 根本原因：标准
ServeMux没暴露底层map，也不支持Unhandle - 替代思路：用自定义
http.Handler包裹一个可读写的路由表（如sync.RWMutex+map[string]http.HandlerFunc）
用 sync.RWMutex 实现可热更的简易路由表
核心是绕过 ServeMux，自己实现 http.Handler 接口，把请求路径查表逻辑收归己有。适合轻量场景，不依赖外部包。
type DynamicRouter struct {
mu sync.RWMutex
route map[string]http.HandlerFunc
}
func (r *DynamicRouter) ServeHTTP(w http.ResponseWriter, req *http.Request) {
r.mu.RLock()
handler, ok := r.route[req.URL.Path]
r.mu.RUnlock()
if !ok {
http.NotFound(w, req)
return
}
handler(w, req)
}
func (r *DynamicRouter) Add(path string, h http.HandlerFunc) {
r.mu.Lock()
defer r.mu.Unlock()
r.route[path] = h
}
func (r *DynamicRouter) Remove(path string) {
r.mu.Lock()
defer r.mu.Unlock()
delete(r.route, path)
}
func NewDynamicRouter() *DynamicRouter {
return &DynamicRouter{
route: make(map[string]http.HandlerFunc),
}
}
- 注意：所有
Add/Remove必须在服务启动后仍可调用，但不要在高并发写路由时频繁增删——读多写少才合适 - 不支持通配符（如
/user/:id）或正则匹配，仅精确路径匹配 - 若需中间件，可在
ServeHTTP中统一加，比如日志、鉴权
用 chi 的 Router 实现带树形匹配的动态路由
chi 的 chi.Router 是可变的，且 Mount、Route、Handle 等方法都允许运行时调用，配合 sync.RWMutex 控制写操作即可安全热更。
立即学习“go语言免费学习笔记（深入）”；
var (
mu sync.RWMutex
router = chi.NewRouter()
)
func AddRoute(pattern string, h http.HandlerFunc) {
mu.Lock()
defer mu.Unlock()
router.Get(pattern, h)
}
func RemoveRoute(pattern string) {
// chi 不提供原生 Remove，需自行维护子 router 或重载整个树
// 更实际的做法：用独立子 router + Mount，替换 mount 点
}
-
chi支持:id、*filepath等，比纯 map 强得多 - 真正「删除」路由较麻烦——
chi没暴露内部 trie 结构，推荐方案是：为动态路由单独建一个chi.Router，然后router.Mount("/api", dynamicSubRouter)，更新时新建子 router 替换旧的 - 务必注意：每次
Mount后，旧子 router 不再被引用，GC 会回收，但正在处理的请求不受影响
生产环境注意事项
动态路由不是银弹。多数服务的路由结构在启动时就应收敛，运行时变更通常只用于插件系统、灰度 API、或低频管理后台。
- 热更失败不易观测：建议每次
AddRoute后发一次GET请求自检，比如访问/health/route?path=/test - 别把路由表存在内存里就完事——没持久化、没集群同步。多实例部署时，需配合 Redis 或配置中心广播变更事件
- 调试困难：
chi.DebugPrinter只能打印启动时的路由树，运行时新增的不会自动显示，得自己实现PrintRoutes()遍历内部结构（不推荐，耦合太强） - 最稳妥的「动态」其实是重启+配置文件热加载（如
viper.WatchConfig），比内存改路由更可控
