http.ServeMux不能直接做路由分组，因其仅支持简单前缀匹配，不支持嵌套、中间件、路径参数解析或分组级逻辑注入，设计上专注基础请求分发。
为什么 http.ServeMux 不能直接做路由分组
Go 标准库的 http.ServeMux 是一个简单的前缀匹配路由器，它不支持嵌套、中间件、参数提取或路径变量。比如你注册了 /api/v1/users 和 /api/v1/posts，想统一加 /api/v1/ 前缀并绑定日志中间件——http.ServeMux 没法帮你“分组”管理，只能重复写前缀，也无法在分组层级插入逻辑。
这不是设计缺陷，而是标准库的取舍：它只负责把请求分发到 handler，其余交给上层框架或手动封装。
- 它不解析路径参数（如
/users/{id}） - 没有中间件链机制
- 无法为某段路径批量设置 header、超时或 recovery
- 注册顺序不影响匹配逻辑（纯前缀最长匹配），但也不支持优先级控制
用 gorilla/mux 实现带中间件的分组路由
gorilla/mux 是最常用的增强型路由器，它的 Subrouter() 方法天然支持分组。关键点在于：子路由继承父路由的路径前缀和中间件，且可独立追加新中间件。
router := mux.NewRouter()
api := router.PathPrefix("/api/v1").Subrouter()
api.Use(loggingMiddleware, authMiddleware) // 分组级中间件
api.HandleFunc("/users", listUsers).Methods("GET")
api.HandleFunc("/users/{id}", getUser).Methods("GET")
admin := router.PathPrefix("/admin").Subrouter()
admin.Use(adminOnlyMiddleware)
admin.HandleFunc("/dashboard", showDashboard).Methods("GET")
注意：Subrouter() 返回的新路由器仍需挂载到主路由下（它自动完成），但中间件只对本子树生效；路径变量 {id} 会由 mux.Vars(r) 提取，不是标准库能处理的。
立即学习“go语言免费学习笔记（深入）”；
- 子路由的
PathPrefix必须以/开头，否则 panic -
Use()添加的中间件按注册顺序执行，不可逆序 - 若在子路由上调用
HandleFunc("", ...)（空路径），它会匹配父前缀下的根路径，比如/api/v1/
自己封装轻量分组：基于 http.Handler 的组合
如果不想引入第三方，可以用 Go 的接口组合能力手写分组。核心是实现一个接受前缀和中间件的构造函数，返回 http.Handler：
type Group struct {
prefix string
handlers []func(http.Handler) http.Handler
mux *http.ServeMux
}
func NewGroup(prefix string, middlewares ...func(http.Handler) http.Handler) *Group {
return &Group{
prefix: prefix,
handlers: middlewares,
mux: http.NewServeMux(),
}
}
func (g *Group) Handle(pattern string, h http.Handler) {
fullPattern := g.prefix + pattern
https://www.php.cn/link/df7c6cbfde52a0ccf19c3a82487c3ca5 := h
for i := len(g.handlers) - 1; i >= 0; i-- {
https://www.php.cn/link/df7c6cbfde52a0ccf19c3a82487c3ca5 = g.handlersi
}
g.mux.Handle(fullPattern, https://www.php.cn/link/df7c6cbfde52a0ccf19c3a82487c3ca5)
}
使用时：
api := NewGroup("/api/v1", logging, auth)
api.Handle("/users", http.HandlerFunc(listUsers))
api.Handle("/posts", http.HandlerFunc(listPosts))
mainMux := http.NewServeMux()
mainMux.Handle("/", api) // 注意：这里要挂载整个 Group，不是它的 mux
这个模式的关键是：分组本身是 http.Handler，内部用 ServeHTTP 做路径裁剪和委托。容易出错的地方是路径拼接没去重 //、中间件执行顺序写反、忘记调用 mainMux.Handle 导致 404。
分组设计中真正难的是中间件生命周期与错误传播
路由分组只是表象，真正的复杂度藏在中间件如何协作。比如一个分组里同时有 auth、rateLimit、panicRecovery，它们的包裹顺序直接影响行为：
-
panicRecovery必须最外层，否则 panic 会穿透出去 -
rateLimit应在auth之后，避免未登录用户耗尽配额 - 如果某个中间件需要读取 body（如鉴权 token 解析），必须确保它在其他读 body 的中间件之前，否则 body 已被消费
- 分组级中间件若返回 error，标准
http.Handler接口无法透出，只能靠写 response 或 panic，这会让错误处理变得隐晦
所以与其纠结“怎么分组”，不如先明确每个分组的语义边界（API 版本？权限域？服务模块？），再决定哪些逻辑必须在分组入口统一处理——很多场景下，分组只是组织手段，真正的约束靠文档和 Code Review 更可靠。
