Gin中/user/:id会吃掉/user/new，是因为Radix Tree将:id视为覆盖/user/下所有未显式注册子路径的动态节点；必须先注册/user/new使其成为独立叶子节点，否则请求被:id拦截并错误赋值c.Param("id")=="new"。
为什么 /user/:id 会吃掉 /user/new
不是注册顺序写反了，而是 Radix Tree 的节点构建逻辑决定的：/user/:id 是一个「动态段节点」，它在树中代表 /user/ 下所有未被显式声明的子路径。只要 /user/new 没被提前注册为独立叶子节点，请求就会被 :id 吞掉，c.Param("id") 拿到的值就是 "new"，但 handler 根本没打算处理这个 case。
-
/user/new必须在/user/:id之前注册，让 Trie 树为它单独生成分支 - 注册顺序不能靠“后注册覆盖前注册”——Gin 不支持覆盖，重复注册同 Method + 同 Path 会直接 panic
-
router.Group("/user")不改变优先级，只是拼前缀，组内路由仍要遵守「具体在前、泛化在后」
Gin 路由匹配到底按什么优先
Gin 不是纯看注册顺序，也不是纯看谁更“语义精确”，而是基于 Radix Tree 的「最长静态路径匹配」：静态路径（如 /v1/users/profile）永远比同级动态路径（如 /v1/users/:id）优先；若两者路径长度相同（比如 /v1/:id 和 /v1/profile），则先注册的胜出。
- 路径长度以字面量为准：
/api/v1/users比/api/v1/:id长，所以一定命中前者 - 带正则的动态路由（如
/v1/{id:[0-9]+}）也属于动态节点，优先级低于同级静态路径 - 通配符
*filepath是 catch-all 类型，匹配优先级最低，但一旦匹配成功，会吞掉整个剩余路径
如何验证路由是否冲突
启动时打印的 [GIN-debug] 日志是最直接证据。重点扫一眼有没有多个相似 Path 的 GET/POST 记录，尤其是混用 :param 和纯字符串路径的情况。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 用
router.Routes()手动遍历检查：pathMap按route.Method + route.Path做 key，发现重复就说明冲突 - 别依赖浏览器 404 判断——可能路由匹配成功了，只是 handler 里逻辑出错
- 如果
gorilla/mux用户转 Gin，注意 mux 是纯线性扫描，而 Gin 是树结构匹配，行为不等价
中间件顺序和路由优先级是两回事
中间件执行顺序只取决于 Use() 调用顺序，和路由匹配无关。你把鉴权中间件塞进 router.Group("/admin")，它不会因此“优先于”全局日志中间件——全局 router.Use() 总是先执行。
- 路由组中间件只影响该组下所有路由的 handler 执行链，不改变路由树中的位置或匹配优先级
- 如果某个中间件调用了
c.Abort()，后续中间件和 handler 都不会执行，但路由本身仍算“已匹配” - 想让某条路由绝对最优先，唯一办法是把它放在整个
router初始化的最早位置，而不是靠中间件“抢”
真正容易被忽略的是：Radix Tree 的节点压缩机制会让看似不同的路径共享父节点，导致你改了一条路由，意外影响另一条——这不是 bug，是结构特性。调试时别只盯着注册顺序，得看 router.Routes() 输出的实际路径树结构。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
