Go 1.22+ 原生 http.ServeMux 支持方法前缀匹配和单段路径通配符（如 "GET /users/{id}"），需显式创建 mux 实例并调用 HandleFunc，不支持正则、跨段通配或子路由。
Go 1.22+ 原生 http.ServeMux 已支持路径参数和方法匹配
不用引入任何第三方库，http.ServeMux 在 Go 1.22（2024年2月发布）起就原生支持 "GET /users/{id}" 这类写法。它不是“模拟”，而是标准库直接解析路径模板、提取参数、按最长前缀+方法优先级匹配。
常见错误是仍用老方式写 mux.HandleFunc("/users/", ...)，结果 {id} 不生效；或者漏写方法前缀，导致所有方法都命中同一 handler。
- 必须带方法前缀：
"GET /users/{id}"、"POST /users"，不写默认匹配所有方法 - 路径参数名不能含下划线或大写字母（只接受
[a-z0-9]+），否则启动时报错invalid pattern - 通配符
{path...}要放在末尾，且只能有一个；/files/{path...}合法，/files/{a...}/{b...}不合法 - 不支持正则约束（如
{id:[0-9]+}），这是httprouter或gorilla/mux的能力
httprouter 的路由匹配基于前缀树 + 正则提取
httprouter 是轻量级代表，它的核心是手动维护的前缀树（trie），每个节点存 handler 和参数名列表。匹配快、内存占用低，但不支持任意正则——只支持 :param 和 *wildcard 两种占位符。
容易踩的坑是误以为它能像 gorilla/mux 那样写 {id:\d+}：实际会直接 panic，错误信息是 invalid pattern: {id:\d+}。
立即学习“go语言免费学习笔记（深入）”；
-
:id提取任意非斜杠字符串，*path提取剩余全部路径（含斜杠） - 参数通过
httprouter.Params传入 handler，不是context.Context，没法直接和标准中间件链对接 - 没有内置中间件机制，要自己包装
http.Handler实现链式调用 - 不兼容
net/http的http.HandlerFunc签名，必须用三参数函数
Gin 路由本质是 httprouter 封装，但加了运行时反射和中间件栈
Gin 默认用 httprouter 作底层引擎，但对外暴露的是更友好的 API。它的路由注册看似简单，背后做了不少事：自动注册同路径不同方法、把中间件压入栈、把 Params 封装进 *gin.Context。
性能损耗主要来自两处：一是 gin.Context 初始化开销（哪怕不用），二是中间件栈里每层都做 Next() 调用判断。
- 路径定义不校验格式，
r.GET("/users/:id", h)中:id会被转成httprouter能认的:id，但写成{id}会静默失败（匹配不到） -
Group不是语法糖，它生成新RouterGroup实例，中间件作用域严格隔离；但嵌套过深会导致Context层级变深，调试时c.FullPath()显示完整拼接路径，不易回溯来源 - 若用
gin.Default()，默认启用了Logger和Recovery中间件，压测时务必切到gin.SetMode(gin.ReleaseMode)，否则性能下降超 50%
选型关键不在“好不好”，而在“要不要为某特性多担一份风险”
比如你只需要 /api/v1/users/{id} 这种结构，且团队对安全审计有硬性要求，http.ServeMux 就是最优解——零第三方依赖、无隐藏行为、升级 Go 版本即得新能力。
但如果你需要 /users/{id:\d+}/posts/{slug:[a-z0-9-]+} 这类带正则约束的路径，或依赖 gorilla/mux 的 host 匹配、scheme 强制等高级规则，那就要接受多一个依赖、多一层抽象、多一点维护成本。
真正容易被忽略的是中间件兼容性：标准库中间件（如 http.StripPrefix）返回 http.Handler，可直接套在 ServeMux 上；但 Gin 或 Fiber 的中间件是框架私有类型，无法跨框架复用，也难对接 Prometheus、OpenTelemetry 等只认 http.Handler 的生态组件。
