net/http.ServeMux仅支持前缀匹配，不支持路径参数、正则约束和优先级控制，且线性遍历导致路由超50条时性能骤降；需用httprouter等radix tree方案实现O(1)匹配。
为什么不用 net/http.ServeMux 做路由分发
net/http.ServeMux 是 Go 标准库默认的 HTTP 路由器，但它只支持前缀匹配（如 /api/），不支持路径参数（如 /user/:id）、正则约束、优先级控制，且底层是线性遍历，路由规则一多性能明显下降。真实服务中一旦路由数超过 50 条，平均匹配耗时就可能从几十纳秒跳到微秒级。
如果你需要路径参数提取、通配符优先级、或每秒处理数万请求，必须换更轻量、确定性 O(1) 或 O(log n) 匹配的方案。
用 httprouter 实现零分配路径匹配
httprouter 是目前最成熟的无反射、无内存分配的高性能路由器，核心靠前缀树（radix tree）实现，匹配过程不 new 对象、不 panic、不依赖 reflect，适合高并发低延迟场景。
- 安装：
go get github.com/julienschmidt/httprouter - 基本用法：注册 handler 时用
:param捕获路径段，*path捕获剩余路径 - 注意：
httprouter不自动处理OPTIONS或 405 方法，需手动注册或加中间件 - 性能关键点：避免在 handler 内做大量字符串拼接或 JSON 序列化——这些操作比路由匹配本身更耗时
示例片段：
立即学习“go语言免费学习笔记（深入）”；
r := httprouter.New()
r.GET("/user/:id", func(w http.ResponseWriter, r *http.Request, ps httprouter.Params) {
id := ps.ByName("id") // 不会 panic，未匹配时返回空字符串
fmt.Fprintf(w, "user %s", id)
})
自己写一个极简 radix tree 路由器的关键判断点
如果项目要求完全可控、无第三方依赖，或需嵌入到已有框架中，可手写最小可行 radix tree。重点不在“完整”，而在“不踩坑”：
- 节点必须区分
static和param子节点类型，否则无法支持/api/:version/users这类混合路径 - 匹配时要严格按路径段（
strings.Split(path, "/")）切分，不能直接用strings.HasPrefix—— 否则/a会错误匹配/abc - 通配符
*必须是叶子节点唯一子节点，且只能出现在末尾，否则语义模糊 - 调试时打印匹配路径和实际路径对比，常见错误是漏掉开头的
/或结尾多余斜杠导致全不匹配
gin 的 Engine 路由器能直接复用吗
可以，但要注意它不是“开箱即用”的独立模块：gin.Engine 是完整 Web 框架核心，耦合了中间件栈、上下文封装、日志、恢复 panic 等逻辑。若只想要它的路由能力，需剥离 gin.RouterGroup 和 tree 包，但官方不保证这部分 API 稳定——v1.10+ 中 gin.tree 已移至内部包，无法直接 import。
更稳妥的做法是：用 gin 的路由逻辑作参考（它也是 radix tree），但抄其算法而非直接引用。GitHub 上有多个精简版实现（如 go-pkg/radix），可验证后再集成。
真正容易被忽略的是：所有高性能路由器都假设输入路径已标准化（无重复斜杠、无 ..、无查询参数）。实际生产中必须在路由前做 url.PathEscape 或 cleanPath 预处理，否则 /a//b 或 /../secret 可能绕过匹配逻辑。
