Gin为每种HTTP方法维护独立的基数树，GET("/x")和POST("/x")分别插入不同树中，请求时先按Method选择对应树再匹配路径，故不冲突。
直接说结论：Gin 的路由方法匹配不是靠字符串比对，而是由底层 httprouter 基于基数树（Radix Tree）在注册阶段就固化了路径与 HTTP 方法的映射关系；GET、POST 等快捷方法只是 Handle 的语法糖，不能靠运行时“动态切换”方法。
为什么 router.GET("/x", h) 和 router.POST("/x", h) 不冲突
Gin 为每种 HTTP 方法维护一棵独立的基数树。注册 GET("/x") 会插入到 GET 树，POST("/x") 插入到 POST 树，互不影响。请求进来时，框架先看 c.Request.Method，再查对应树——所以同路径不同方法天然隔离。
- 不写
router.OPTIONS("/x", ...)，客户端发OPTIONS /x就会 404（除非你显式配了NoRoute或中间件兜底） -
router.Any("/x", ...)是把同一路径注册进所有方法树，等价于手动调用 7 次Handle - 如果你只注册了
GET，但客户端用POST访问，不会触发任何 handler，也不会 fallback 到GET—— 这不是 bug，是设计
Handle() 与 GET/POST 快捷方法的本质区别
Handle("METHOD", path, h) 是底层原语，GET、POST 等全是它封装的别名。二者行为完全一致，但 Handle 允许传入任意字符串作为 method，比如自定义 WebDAV 方法：
Skill Weave Chains — 技能链路由引擎
下载
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
r.Handle("PROPFIND", "/files/*path", propfindHandler)
r.Handle("MKCOL", "/files/*path", mkcolHandler)
- 快捷方法不支持非标准 method（如
SEARCH、LOCK），必须用Handle -
Handle第二个参数relativePath支持通配符（*path），而快捷方法对通配符的支持是一致的，没差别 - 不要试图用
Handle("get", ...)（小写）——method 字符串区分大小写，必须大写（"GET"）
常见错误：NoRoute 没生效？检查 method 是否真的未注册
NoRoute 只捕获「路径存在但当前请求 method 无 handler」的情况。它不是万能兜底：
- 如果请求是
PUT /missing，且你没注册任何PUT路由，NoRoute会触发 - 但如果请求是
PUT /existing，而你只注册了GET("/existing")，NoRoute不会触发——因为路径/existing在 PUT 树里根本不存在，Gin 会直接返回 405 Method Not Allowed - 想统一处理所有未匹配 method+path 组合，得用
Match([]string{"GET","POST","PUT","DELETE","PATCH","HEAD","OPTIONS"}, path, h)
路由优先级和匹配顺序容易被忽略的点
Gin 的基数树按「静态路径 > 命名参数（:id） > 通配符（*path）」三级优先级排序，但这个顺序只在同一 method 树内生效：
-
GET("/users/:id")和GET("/users/me")同时存在时，/users/me一定先匹配（静态路径优先） -
GET("/files/*path")会匹配/files/a/b/c，但不会匹配/files（末尾缺斜杠），除非你额外注册GET("/files") - 不同 method 的同路径路由之间没有优先级——
POST("/api")和GET("/api")完全无关，不会互相遮蔽
真正容易出问题的是开发时习惯性只测 GET，上线后前端发了 POST 却没配 handler，结果返回 404 或 405 而不是预期逻辑——method 匹配不是“模糊容错”，是精确开关。
