Gin路由不用map而用前缀树，因map仅支持静态精确匹配，无法处理:id、*filepath等动态规则；前缀树通过路径分段、公共前缀复用、参数与通配节点匹配，实现O(k)时间复杂度的高效路由。
为什么 Gin 的路由不直接用 map 而要用前缀树
因为 map 只能精确匹配静态路径，无法处理 :id、*filepath 这类动态规则。Gin 的 GET("/user/:id") 能匹配 /user/123 和 /user/abc，map 没法在不遍历全部键的前提下做到这点。
前缀树（Radix Tree）把路径按 / 拆成段，逐层比对节点，天然支持：
- 公共前缀复用（
/api/v1/users和/api/v1/posts共享/api/v1节点） - 参数占位符匹配（遇到
:id节点时，跳过具体值，只记录键名） - 通配后缀捕获（
*filepath节点会吃掉剩余所有段）
时间复杂度是 O(k)（k 是路径段数），不是 O(n)（n 是注册路由总数），这才是高并发下不拖慢的关键。
手写前缀树路由时，node 结构必须包含哪些字段
不能只存子节点列表。Gin 源码里的 node 至少要带这四个信息：
立即学习“go语言免费学习笔记（深入）”；
-
path：当前节点代表的路径段（如"user"或":id"） -
children：子节点切片，用于树形遍历 -
isWild：标记是否为:param类型节点（非字面量匹配） -
handler：命中该节点时执行的函数（nil 表示中间节点）
漏掉 isWild 就没法区分 /user/:id 和 /user/id；没存 handler 就没法绑定业务逻辑。Gin 的 tree.go 里还额外加了 nType 字段区分静态/参数/通配节点，但最小可用版本只需上面四点。
router.Add() 注册路由时，路径分段和节点插入的顺序怎么处理
必须按 / 切分后从左到右逐段插入，且每段都要考虑三种情况：
- 当前段是普通字符串（如
"user"）→ 直接作为子节点追加 - 当前段以
:开头（如":id"）→ 创建isWild=true节点，且该节点必须是其父节点的**最后一个子节点**（否则会干扰精确匹配） - 当前段是
*开头（如"*filepath"）→ 创建通配节点，且必须是整棵树的**最末节点**，不能再有子节点
顺序错乱会导致匹配失效：比如把 :id 插在 "user" 前面，/user/123 就会先被 :id 吃掉，根本走不到 user 分支。
匹配 /api/v1/:id 这种多级路径时，router.Find() 怎么避免回溯
Gin 不回溯。它的匹配逻辑是单向推进的：
- 请求路径按
/拆成["api", "v1", "123"] - 从根节点开始，第一段
"api"→ 找到对应子节点 - 第二段
"v1"→ 在上层节点的children中继续找 - 第三段
"123"→ 此时当前节点的子节点里没有"123"，但有一个isWild=true的":id"节点 → 接受匹配，并将"123"绑定到params["id"]
关键点在于：wild 节点只在「当前层无精确匹配」时才启用，且一旦命中就终止该层搜索。这也是为什么 Gin 的 tree.Search() 函数里没有递归调用或栈操作——它就是个线性扫描 + 条件跳转。
真正容易被忽略的是通配节点 *filepath 的优先级：它必须比所有 wild 和 static 节点都低，否则 /static/js/app.js 会被错误地匹配进 /static/* 而不是更具体的 /static/js/*（如果存在的话）。这个优先级靠插入顺序和查找时的遍历顺序共同保证。
