标准库 http.servemux 不适合高并发路径匹配，因其线性遍历 o(n)、不支持路径参数与通配符；trie 树可优化至 o(m) 并天然支持动态路由，但需严格区分静态/参数/通配符子节点、校验插入顺序、复用 params map 与路径切片以避免 gc 压力。
为什么标准库的 http.ServeMux 不适合高并发路径匹配
因为它是线性遍历所有注册路由，时间复杂度 O(n)，且不支持路径参数（如 /user/:id）和通配符（如 /static/*filepath）。当路由数过百、QPS 上千时，匹配延迟会明显上升，尤其在微服务网关或 API 网关场景下，这成了瓶颈。
而 Trie 树（前缀树）能将路径按段拆解、逐级下沉，匹配时间接近 O(m)，m 是路径段数；配合子节点类型标记（静态/参数/通配符），还能自然支持动态路由语义。但注意：Trie 本身不解决“最长前缀匹配”冲突，必须显式设计节点优先级规则。
trieNode 必须区分三种子节点类型
实际写的时候，如果只用一个 map[string]*trieNode 存子节点，就无法区分 /user/:id 和 /user/profile —— 因为 :id 是参数占位符，不是真实路径段。必须把子节点按语义分类：
-
children：存放纯静态路径段，如"user"、"profile" -
paramChild：最多一个，对应:param类型，如/user/:id中的:id -
wildcardChild：最多一个，对应*类型，如/static/*filepath
插入时需严格校验顺序：通配符只能出现在末尾，参数不能跟在通配符后；否则匹配逻辑会歧义。例如 /api/v1/*path/:id 是非法的，解析阶段就要报错 ErrInvalidPattern。
匹配时如何处理 :param 和 *wildcard 的捕获逻辑
关键不是“找到节点”，而是“在下降过程中累积参数值”。建议在匹配函数中传入一个 map[string]string 用于收集参数，并在进入 paramChild 或 wildcardChild 时写入：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
// 示例片段：进入 paramChild 时
if node.paramChild != nil {
paramName := node.paramName // 如 "id"
segment := parts[i] // 如 "123"
params[paramName] = segment
return node.paramChild.match(parts, i+1, params)
}
注意两点：一是 *wildcard 匹配的是剩余全部路径段（包括斜杠），所以要拼接 strings.Join(parts[i:], "/")；二是若当前节点有 handler 且 i == len(parts)，才算完全匹配，否则即使走到叶子也可能只是前缀匹配失败。
性能陷阱：别在每次请求都分配新 params map
高频路由匹配下，频繁 make(map[string]string) 会触发 GC 压力。更稳妥的做法是复用 sync.Pool：
var paramsPool = sync.Pool{
New: func() interface{} {
return make(map[string]string, 4)
},
}
// 使用时：
params := paramsPool.Get().(map[string]string)
defer func() {
for k := range params {
delete(params, k) // 清空，非重置
}
paramsPool.Put(params)
}()
另外，路径切片 strings.Split(r.URL.Path, "/") 也会分配内存。生产环境建议预分配切片并用 strings.TrimPrefix + 自定义分割避免多余分配 —— 尤其当路径深度固定（如 REST API 通常 ≤6 层）时，可直接用栈式循环替代切片。
真正难的不是建树，而是让参数捕获、通配行为、优先级规则三者在各种边界路径下保持一致。比如 /api/:version/users 和 /api/v1/users/:id 同时存在时，/api/v1/users/5 必须命中后者；这个逻辑必须在插入和匹配两个环节都严格对齐，漏掉任一端都会导致静默错误。
