gin路由快是因为采用压缩前缀树（radix tree）而非哈希或遍历，时间复杂度o(k)且与路由数量无关；不同http方法对应独立树，节点压缩共享路径片段，并通过ntype、wildchild、indices等字段高效匹配。
为什么 Gin 路由快？不是哈希，是 Radix Tree
因为 Gin 不用遍历所有路由，也不靠字符串哈希碰撞查找，而是把路径当单词塞进一棵压缩前缀树里。每次请求进来，只顺着路径字符逐层往下找，时间复杂度是 O(k)（k 是 URL 路径长度），和注册了多少条路由完全无关。
常见误解是“Gin 用 map 做路由”，其实 Engine.trees 是个 map[string]*node，key 是 HTTP 方法（如 "GET"、"POST"），value 才是每棵独立的基数树根节点。也就是说：不同方法的路由完全隔离，互不影响。
- 注册
r.GET("/user/:id")→ 写入trees["GET"]这棵树 - 注册
r.POST("/user")→ 写入trees["POST"]这棵树 - 哪怕 GET 和 POST 有相同路径，也不会冲突或覆盖
node 结构里藏着匹配逻辑的关键字段
每个树节点（node）不是只存一个字符，而是存一段**共享前缀路径片段**，比如 /api/v1 可能直接作为一个 path 字段值，而不是拆成 a→p→i→/→v→1 六个节点。这就是“压缩”的本质。
真正决定怎么匹配的，是这几个字段：
-
nType：标识节点类型 ——static（字面量，如"users"）、param（参数，如":id"）、catchAll（通配，如"*filepath"） -
wildChild：布尔值，表示该节点下有没有param或catchAll子节点。匹配失败时，它告诉引擎：“别急着报 404，试试参数或通配规则” -
indices：子节点首字符组成的字符串，比如子节点路径分别是"users"、"upload"、"admin"，那indices就是"uua"—— 用来快速定位要走哪个子分支，避免遍历children切片
路径注册时发生了什么？以 /user/:id 和 /user/list 为例
这两条路由不会生成四个节点，而是共用 "user" 这个父节点，再分出两个子分支：":id" 和 "list"。Gin 的 addRoute() 函数在插入时会做三件事：
- 按
/拆路径 → 得到["", "user", ":id"]（空字符串代表根） - 从根开始逐段匹配：发现已有
"user"节点，就往下走；再看":id"是否已存在子节点 —— 不存在，就新建一个nType=param的节点 - 更新沿途节点的
priority：子节点越多、越常被访问的节点，priority越高，后续匹配时优先尝试高优先级分支
注意："/user/list" 插入时，走到 "user" 后发现没有 "list" 子节点，就新建一个 nType=static 节点。此时 "user" 节点的 wildChild 仍为 false，因为它下面只有静态子节点。
容易踩的坑：参数名重复、通配符位置、树分裂边界
基数树不是黑盒，写错路径会导致树结构异常，轻则匹配失效，重则 panic。
-
:/id和/:name不能共存于同一级 —— Gin 会 panic，报错"two nodes with different wildcards"。因为同一个父节点下，最多只能有一个param类型子节点 -
/static/*filepath必须放在最后注册 —— 它会吃掉所有以/static/开头的路径。如果它注册在/static/js/app.js之前，后者永远无法命中 - 路径末尾带不带
/是两棵不同的树分支 ——/api和/api/在树里是兄弟节点，不是父子关系。浏览器自动补斜杠、反向代理截断斜杠，都可能让请求“掉出树外”
最隐蔽的问题是：树的压缩行为依赖路径的公共前缀长度，但 Gin 不对外暴露树结构。调试时不能只看路由表打印，得用 engine.Delims 或打日志进 node.match() 才能看到真实匹配路径。
