Gin的路由基于压缩前缀树（Radix Tree），时间复杂度O(k)（k为路径段数），非遍历或哈希表；每HTTP方法独享一棵树，节点分static/param/catchAll三类，支持动态参数与通配符，依赖注册顺序与路径语义匹配。
Gin 的路由不是靠遍历匹配，也不是用 map 查 key，而是靠一棵压缩前缀树（Radix Tree）——它决定了你加的每条 r.GET("/user/:id") 最终怎么存、怎么查、为什么快。
Radix Tree 为什么比遍历快？时间复杂度从 O(n) 降到 O(k)
假设你注册了 1000 条路由，传统线性匹配每次都要挨个比对路径字符串，最坏要试 1000 次；而 Radix Tree 把公共前缀合并，查找时只按路径段逐级下钻。比如 /api/v1/users 和 /api/v1/posts 共享 /api/v1 前缀，树里只存一次。
关键点：
- 时间复杂度是
O(k)，k 是 URL 路径段数量（如/user/123/profile是 3 段），和总路由数无关 - 每个 HTTP 方法（
GET、POST）各自维护一棵独立的树，engine.trees["GET"]就是 GET 路由树根节点 - 不依赖反射，纯指针跳转，几乎没有额外开销
三种节点类型决定路由行为：static / param / catchAll
Radix Tree 不是简单字符树，它区分语义：静态路径、参数路径、通配路径。这直接影响你写路由时能不能匹配成功。
常见现象：
-
/user/:id→ 注册为param类型节点，node.nType == param，node.paramName == "id" -
/file/*filepath→ 注册为catchAll类型节点，必须放在最后，否则会拦截所有子路径 -
/health→static类型，精确匹配，优先级高于param（同级时 static > param > catchAll） - 错误写法：
/user/:id/profile和/user/:id同时存在时，前者会先被匹配，后者不会被覆盖——但若顺序颠倒，可能因优先级导致意外交互
路由插入时的路径拆分与节点合并逻辑
调用 r.GET("/admin/api/v2/users") 时，Gin 会把路径按 / 拆成 ["admin", "api", "v2", "users"]，再逐段插入树中。过程中会主动压缩冗余节点。
例如连续注册：
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
/a/b/c/a/b/d
不会生成 6 个节点，而是合并出 /a/b 公共父节点，再挂 c 和 d 两个子节点。这就是“压缩前缀”的实质。
源码关键字段说明：
-
node.path：当前节点代表的路径段（如"users"） -
node.indices：子节点首字符组成的字符串（如子节点是"list"和"create"，则indices == "lc"），用于快速索引 -
node.wildChild：标记该节点是否有:param或*catchall子节点，影响匹配回溯逻辑
调试时怎么看路由树长什么样？
Gin 不提供官方树形打印工具，但你可以临时加一行日志观察注册效果：
func main() {
r := gin.New()
r.GET("/user/:id", func(c *gin.Context) {})
r.POST("/user", func(c *gin.Context) {})
// 打印所有已注册路由（非树结构，但可验证是否注册成功）
for _, routes := range r.Routes() {
fmt.Printf("%s %s\n", routes.Method, routes.Path)
}
r.Run(":8080")
}
真正要看树结构，得进 github.com/gin-gonic/gin/tree.go，在 addRoute 函数末尾加断点或 log —— 但多数时候没必要。真正容易出问题的是：
- 把
catchAll路由（如/static/*filepath）写在了param路由（如/user/:id）前面，导致后者永远不命中 - 路径结尾多写了
/（如r.GET("/api/", handler)），实际匹配需要严格带尾部斜杠 - 用
Group时前缀没处理好，比如g := r.Group("/v1")再g.GET("user")，最终路径是/v1/user，不是/user
基数树本身很稳定，问题几乎都出在路径定义和注册顺序上，而不是树实现。
