Gin路由冲突的根本原因是Radix Tree结构特性：/user/:id作为参数节点会覆盖/user/下所有未显式注册的子路径；必须先注册/user/new等静态路径以构建独立叶子节点，否则请求会被:id拦截并返回c.Param("id")=="new"。
Gin 的路由不会“覆盖”，只会“被吞”——根本原因不是注册顺序错，而是 Radix Tree 结构里没给静态路径留出独立分支。
为什么 /user/:id 会吃掉 /user/new
这不是注册先后的问题，而是 Gin 的前缀树（Radix Tree）在构建时，/user/:id 作为 param 节点，天然代表「/user/ 下所有未显式声明的子路径」。如果 /user/new 没在 /user/:id 之前注册，树中就不会为它生成叶子节点，请求进来时直接匹配到 :id 分支，c.Param("id") 就是 "new"。
- 错误写法：
r.GET("/user/:id", h1)在前，r.GET("/user/new", h2)在后 → 后者完全不生效 - 正确写法：必须把
/user/new放前面，再注册/user/:id - 更稳方案：改用语义隔离路径，比如
/user/create或/users/new，避开同级动态段
router.Group() 不改变优先级，只是拼路径
router.Group("/v1") 是语法糖，内部仍是把路径拼接后插入同一棵前缀树。你在 group 里写 v1.GET("/users/:id", h)，和直接写 r.GET("/v1/users/:id", h) 在树中的位置、优先级完全一致。
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- Group 内的注册顺序仍需遵守「具体在前、泛化在后」，它不自动重排
- Group 也不让组内路由比组外同级路径（如
/health）更优先 - 想强制某条路由最优先？唯一可靠方式是把它放在整个
gin.Engine初始化的最早位置
如何验证是否真有路由冲突
启动日志里的 [GIN-debug] 行就是第一手证据。重点看是否有多个相似路径共存，尤其是 /api/v1/users/:id 和 /api/v1/users/profile 这类混用场景。
- 运行时检查：
router.Routes()返回所有已注册路由，可按Method + Path分组统计重复项 - 注意：Gin 不支持同路径同方法重复注册，会 panic，所以看到两个
GET /users/:id说明代码里调了两次 - 如果
c.Param("id")总是空，大概率不是解析失败，而是请求压根没走到那条带参数的路由上——先查匹配路径、方法、Host、Scheme 是否全对得上
通配符 *filepath 是性能黑洞，且破坏前缀剪枝
r.GET("/static/*filepath", h) 这种 catchAll 路由一旦注册，就会让整棵子树失去前缀压缩能力，匹配退化为线性扫描，而且它永远排在最后尝试。
- 别在根路径或高频路径下滥用
*filepath，比如GET "/*filepath"会拖垮全部路由性能 - 静态文件兜底路由必须放最后，否则会吞掉所有本该命中 API 的请求
- 若需后缀匹配（如
.html），优先用NoRoute或中间件判断，而不是靠/*suffix去抢
真正难调试的不是“哪条路由没注册”，而是“哪条路由被结构吞掉了”——Radix Tree 不暴露节点细节，只能靠启动日志 + 路径字面量顺序 + 显式构造静态分支来控制行为。
