因为前缀树支持路径参数（如/users/:id）和通配符（如/static/*filepath）的动态匹配，而map仅支持完全匹配、正则匹配时间复杂度为O(n)；Trie按/拆段逐级匹配，复杂度降为O(k)，且需通过kind标记、分离paramChild/wildcardChild指针来区分静态/参数/通配节点语义。
为什么用前缀树（Trie）而不是 map 或正则匹配
因为 HTTP 路由需要支持带参数的路径（如 /users/:id）、通配符（如 /static/*filepath），且要兼顾插入、查找、回溯的效率。用 map[string]Handler 无法处理带变量段的路径；用正则逐条匹配，时间复杂度是 O(n)，路由多时明显变慢；而前缀树把路径按 `/` 拆成节点，查找是 O(k)，k 是路径段数，天然适合层级化路径匹配。
如何设计 Trie 节点结构以支持 :param 和 *wildcard
普通 Trie 只存字符，但路由需要语义：区分静态段、命名参数、通配符。所以每个节点必须携带类型标记和子节点映射：
-
kind字段取值为KindStatic/KindParam/KindWildcard - 只允许最多一个
KindParam子节点（对应:id），且必须是该层唯一能匹配未命中静态段的兜底节点 -
KindWildcard子节点必须是该层最后一个，且不允许多个或与其他 kind 共存（否则歧义） - 实际存储时，用
map[string]*node存静态子节点，另用单独字段paramChild和wildcardChild避免 key 冲突（比如:id和*path不能当 map key 直接塞进去）
匹配逻辑里最容易漏掉的边界情况
写匹配函数时，光递归走完路径还不够，常见翻车点有三个：
- 路径末尾多出 `/`（如注册了
/api/users，却用/api/users/请求）——需在插入时标准化结尾，或匹配时容忍 trailing slash（但需约定统一行为） - 参数段为空，比如
/posts/:id匹配/posts/—— 必须检查:id对应段长度 > 0，否则会错误捕获空字符串 - 通配符节点后仍有剩余路径段，比如
/static/*file匹配/static/a/b/c，要确保*file吃掉全部剩余段，而非只吃一段 —— 实现时需把剩余路径拼成字符串赋给file，不能只取最后一段
性能关键：插入和匹配都要避免字符串切片拷贝
Go 中频繁 strings.Split(path, "/") 会产生大量小对象，尤其高并发下 GC 压力大。更优做法是用双指针原地扫描：
立即学习“go语言免费学习笔记（深入）”；
for i, j := 0, 0; j <= len(path); j++ {
if j == len(path) || path[j] == '/' {
segment := path[i:j]
// 处理 segment，然后 i = j + 1
i = j + 1
}
}
匹配时同理，传入原始 path 和当前起始索引 start，每次找下一个 / 位置，避免生成中间 []string。实测在万级路由下，内存分配减少 40%+，延迟更稳。
:param 和 *wildcard 在同一层共存又不冲突，以及怎么让匹配结果能干净地返回参数 map 而不卡在某个节点分支里。这些细节不写进节点状态机，后面加中间件或重定向时就会反复踩坑。 
