gin基础路由通过r.get、r.post等方法将http方法与路径映射到处理函数，支持路径参数（如/user/:id）、分组（如r.group("/api/v1")）和中间件，底层基于压缩trie树实现高效匹配。
直接用 r.GET、r.POST 等方法注册路由就能完成基础分发，但真实项目里必须配合路径参数、分组和中间件才能可靠支撑业务逻辑，否则很快会陷入路由散乱、权限失控、版本混乱的问题。
如何用 HTTP 方法 + 路径注册基础路由
Gin 的路由分发起点就是把请求方法和路径字符串映射到处理函数。它不依赖反射或配置文件，全靠代码显式声明。
-
r.GET("/ping", func(c *gin.Context) { c.String(200, "pong") })这种写法只响应GET /ping，对POST /ping会直接返回 404 - 所有标准方法都可用：
r.POST、r.PUT、r.DELETE、r.PATCH、r.HEAD、r.OPTIONS，没有例外 - 如果想让一个路径接受任意方法（比如调试用的通用入口），用
r.Any("/debug", handler)，但生产环境慎用 - 注意大小写敏感：路径
/User和/user是两个不同路由，Gin 默认不自动重定向
怎么提取 URL 中的动态部分（如 /user/123）
硬编码每个 ID 显然不可行，Gin 用冒号前缀标记路径参数，匹配时自动提取并注入上下文。
Skill Weave Chains — 技能链路由引擎
下载
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- 写法是
r.GET("/user/:id", handler)，其中:id是占位符，不是正则也不是通配符 - 在 handler 里用
c.Param("id")获取值，它返回string类型，需自行转类型（比如strconv.Atoi） - 多个参数支持连写：
/user/:uid/book/:bid，分别用c.Param("uid")和c.Param("bid") - 错误写法：
/user/:id/结尾带斜杠——Gin 会把它当静态路径，:id不生效；正确是/user/:id（无尾部斜杠）
为什么必须用 Group 处理模块化接口（如 /api/v1/users）
当接口超过十几个，把所有路由平铺在根引擎上会导致维护困难、中间件无法复用、版本升级牵一发而动全身。
- 用
v1 := r.Group("/api/v1")创建分组，后续所有v1.GET、v1.POST的路径都会自动拼上前缀 - 分组可嵌套：
users := v1.Group("/users")，再写users.GET("")对应/api/v1/users - 中间件绑定到分组：
v1.Use(AuthMiddleware())，该分组下所有路由自动受保护，不用每个都写 - 常见陷阱：分组后忘记调用
.GET等方法，而是误写成v1.GET("/api/v1/users", ...)——这会变成/api/v1/api/v1/users，多了一层前缀
容易被忽略的匹配细节和性能影响
路由匹配不是简单字符串查找，Gin 底层用压缩 Trie 树实现，路径结构直接影响匹配效率和歧义行为。
- 路径末尾斜杠有语义：
r.GET("/files", ...)和r.GET("/files/", ...)是两个独立路由；若只注册了前者，访问/files/会 404（除非启用RedirectTrailingSlash） - 通配符
*filepath必须放在最后，且只能出现一次：r.GET("/static/*filepath", ...)合法，/static/*a/b/*c不合法 - 路径参数和通配符不能混用：
/user/:id/*rest是非法定义，启动时报 panic - 大量嵌套路由（如 5 层以上分组）不会显著拖慢匹配，但会让路由树深度增加，调试时
gin.DebugPrintRouteFunc输出更难读
