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 控制写操作即可安全热更。

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），比内存改路由更可控