Gin路由快是因为使用radix树实现O(k)匹配，与路由数量无关；每种HTTP方法独立路由树，节点含path/indices/wildChild/nType/handlers字段，注册时按前缀压缩构建。
Gin 的路由快不是靠黑魔法，而是因为 radix tree 在匹配时根本不用遍历所有注册路径——只要路径长度固定，匹配就是 O(k) 时间，和你注册了 10 条还是 10000 条路由无关。
Radix 树为什么比 map 查找快 40 倍
net/http 默认用 map[string]HandlerFunc 存静态路径，但这种结构对 /user/:id 这类带参数的路径完全无能为力：它没法做前缀匹配，更没法提取参数。Gin 把 /user/:id 拆成节点序列，在树上逐段跳转，全程不 new string、不拼接 path、不遍历路由表。
- 静态路径（如
/health）走完全匹配分支，O(1) 完成 - 参数路径（如
/user/:id）只在节点标记isParam=true，参数值惰性提取，不提前解析 - 通配符路径（如
/static/*filepath）单独作为子树处理，不影响常规路由性能 - 陷阱：大量混用
/:name+/*path会导致树深度增加，实测 >7 层后匹配耗时明显上升
每种 HTTP 方法都有一棵独立的路由树
Gin 的 Engine.trees 是个 map[string]*node，key 是 "GET"、"POST" 等方法名，value 是对应方法的 radix 树根节点。这意味着你在 GET 和 POST 下注册同名路径（如 /api/user），它们互不干扰，也不共享节点。
- 避免了每个节点里存
map[string]HandlerFunc的内存开销 - 请求进来时，先根据
req.Method拿到对应树，再开始匹配，省掉一层 method 判断 - 源码中关键入口是
engine.trees.get(method)，然后调用root.addRoute(path, handlers)
节点结构决定匹配行为
每个 node 结构体里藏着路由语义的关键字段：
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
-
path：当前节点代表的路径片段（如"user"或":id"） -
indices：子节点首字符索引字符串（如"l:"表示下层有list和:id两个子节点） -
wildChild：是否含通配符子节点，影响回溯逻辑 -
nType：区分static、param、catchAll三类节点，决定如何提取参数 -
handlers：命中该节点时要执行的[]HandlerFunc，也就是中间件链 + 最终 handler
路由注册时的树构建细节
调用 r.GET("/user/:id", handler) 实际触发的是 engine.addRoute("GET", "/user/:id", handlers)，这个过程不是简单插入，而是按前缀压缩规则递归构造节点：
- 公共前缀（如
/user）会被合并成一个节点，而不是拆成/→u→s→e→r -
:id被识别为参数节点，生成node{path: ":id", nType: param, paramName: "id"} - 如果已存在
/user/list，则/user节点下会同时挂:id和list两个子节点，靠indices字符串快速索引 - 注册顺序不影响树结构，但会影响相同路径下多个 handler 的执行顺序（因为
handlers是 slice）
真正容易被忽略的是：radix 树的性能优势只在线性路径匹配阶段成立；一旦你频繁调用 c.Copy()、在 handler 里做大量反射或 JSON 序列化，前面省下的那点 CPU 就全搭进去了。
