Go标准库http.ServeMux仅支持前缀匹配，不支持路径参数、方法限制、中间件；gorilla/mux提供RESTful路由、正则约束和子路由；自定义路由器可实现方法分发但无动态路径提取。
Go标准库http.ServeMux能用，但要注意它不支持路径参数和通配符
Go原生net/http包里的http.ServeMux是最轻量的路由选择，适合静态路径映射。但它只做前缀匹配，比如注册/api/users，实际会同时匹配/api/users/123和/api/users/delete，且无法提取/users/{id}这类路径段。
- 注册方式是
http.HandleFunc("/path", handler)，底层调用DefaultServeMux.HandleFunc - 不区分
GET/POST，所有方法都走同一个HandlerFunc，需手动检查r.Method - 没有中间件机制，鉴权、日志等逻辑要重复写在每个handler里
- 路径末尾斜杠行为特殊：
/admin和/admin/被视为不同路由
第三方路由器如gorilla/mux才真正支持RESTful路由
如果需要路径参数、方法限制、子路由或中间件，gorilla/mux仍是目前最稳定的选择。它兼容http.Handler接口，可直接替换DefaultServeMux。
- 用
router.HandleFunc("/users/{id}", handler).Methods("GET")明确限定方法 -
vars := mux.Vars(r)获取{id}值，返回map[string]string - 支持正则约束：
router.HandleFunc("/users/{id:[0-9]+}", handler) - 子路由可复用中间件：
adminRouter := router.PathPrefix("/admin").Subrouter() - 注意：v1.8+版本已归档，但代码仍可安全使用；新项目可考虑
chi（更轻、API更简洁）
自定义简单路由器只需实现http.Handler接口
不需要完整框架时，几行代码就能写出支持方法分发和路径分割的简易路由器。核心是解析r.URL.Path并比对，再根据r.Method调用对应函数。
type Router struct {
routes map[string]map[string]http.HandlerFunc // method -> path -> handler
}
func (r *Router) ServeHTTP(w http.ResponseWriter, req *http.Request) {
if handler, ok := r.routes[req.Method][req.URL.Path]; ok {
handler(w, req)
return
}
http.Error(w, "Not Found", http.StatusNotFound)
}
func (r *Router) GET(path string, f http.HandlerFunc) {
if r.routes["GET"] == nil {
r.routes["GET"] = make(map[string]http.HandlerFunc)
}
r.routes["GET"][path] = f
}
- 这种结构不支持
/user/:id，但足够应付CLI工具API或内部服务 - 注意
http.ServeMux会自动重定向末尾带斜杠的路径，而自定义路由器不会——需自行处理/admin→/admin/跳转 - 路径匹配顺序完全由代码决定，无“最长匹配”逻辑，注册顺序不影响结果
HTTP路由性能差异其实很小，瓶颈通常不在匹配算法上
实测中，从http.ServeMux换到gorilla/mux或chi，QPS变化几乎不可测（相同硬件下差异
-
gorilla/mux用前缀树+正则回溯，chi用手工写的trie，两者在万级路由下才有明显区别 - 别过早优化路由层：先加
pprof确认热点，再决定是否换库 - 若用
http.ServeMux，避免注册过多重复前缀（如/v1/a、/v1/b、/v1/c），它内部是线性查找
路径参数解析和中间件链式调用带来的可维护性提升，远比微秒级匹配开销重要。选库时优先看文档清晰度和错误提示是否友好——比如405 Method Not Allowed能不能准确定位到哪条路由没配POST。
