不能直接用strings.hasprefix做路由匹配，因为真实web路由需区分静态路径（如/users）、参数路径（/users/:id）和通配路径（/static/*），且须按优先级顺序匹配；硬编码易导致歧义冲突与嵌套地狱，而trie需显式支持static/param/wildcard三类子节点并提前归一化路径。
为什么不能直接用 strings.HasPrefix 做路由匹配
因为真实 Web 路由不是简单前缀判断：/users 和 /users/:id 需要区分；/api/v1 和 /api/v2 不能互相干扰；通配符 :id 和全匹配 * 必须按优先级生效。硬写字符串切分+条件分支，很快会陷入嵌套地狱和歧义冲突。
Trie 节点设计必须支持三类子节点
标准前缀树只存字符，但路由需要表达语义：静态路径段（如 "users"）、命名参数（":id"）、通配符（"*"）。一个节点的子节点不能只用 map[string]*node，否则 ":id" 和 "123" 会冲突。实际需拆成三个独立字段：
-
staticChildren map[string]*node—— 纯字面量路径段 -
paramChild *node—— 最多一个:xxx段（同一层级不允许重复定义） -
wildcardChild *node—— 最多一个*段（必须在末尾）
这样在匹配时顺序明确：先查 staticChildren，没命中再试 paramChild，最后才 fallback 到 wildcardChild。
匹配函数 match 必须携带路径段切片和当前节点深度
把原始路径 "/api/v1/users/123" 提前 strings.Split(path, "/") 成 []string{"api", "v1", "users", "123"}，避免反复切分。递归匹配时传入 segments 和 index（当前处理到第几个段），而不是拼接中间路径字符串——后者会产生大量临时对象，GC 压力大。
关键逻辑示例（简化版）：
func (n *node) match(segments []string, i int, ps *Params) bool {
if i == len(segments) {
return n.handler != nil // 到底了且有处理器
}
seg := segments[i]
if child := n.staticChildren[seg]; child != nil {
return child.match(segments, i+1, ps)
}
if n.paramChild != nil {
ps.Add("param", seg) // 实际应存键名如 "id"
return n.paramChild.match(segments, i+1, ps)
}
if n.wildcardChild != nil {
ps.Add("*", strings.Join(segments[i:], "/"))
return n.wildcardChild.match(segments, len(segments), ps)
}
return false
}
注册路由时必须检测冲突，否则运行时才报错太晚
比如同时注册 /users/:id 和 /users/profile 是合法的；但 /users/:id 和 /users/:name 就是冲突——两者都试图在同一层占用 paramChild。插入新路由前必须检查：staticChildren 中是否已存在同名段、paramChild 是否非空、wildcardChild 是否非空且新路由不是以 * 结尾。
更隐蔽的坑：/api/* 和 /api/v1/* 不冲突，但 /api/v1/* 和 /api/v1/users 也不冲突；而 /api/* 和 /api/v1/users 会因 staticChildren["v1"] 存在导致 /api/* 的通配逻辑被跳过——这其实是设计使然，不是 bug，但必须文档写清“通配符不降级匹配”。
真正容易被忽略的是：路径中连续多个 /（如 //api//v1）应该在进入匹配前 normalize 掉，否则 strings.Split 会产生空字符串段，破坏层级结构。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
