gin路由基于基数树实现o(k)时间复杂度匹配，r.get("/user/:id")无法匹配/user/123的常见原因是路径末尾斜杠不一致、:id未作为独立路径段使用，或注册与请求路径格式不统一。
Gin 的路由配置不是“写完就生效”的静态映射，而是构建在基数树（Radix tree）上的动态查找结构；请求进来时，Engine.ServeHTTP 会从对象池取 *gin.Context，再按 HTTP 方法 + 路径做 O(k) 时间复杂度的树遍历，最终执行匹配到的 handler 链 —— 这意味着路径写错、方法不匹配、中间件顺序不当，都会直接导致 404 或逻辑异常。
为什么 r.GET("/user/:id") 匹配不了 /user/123？
常见错误是路径中混用斜杠或忽略 trailing slash 行为。Gin 默认不自动重定向末尾斜杠，/user/:id 和 /user/:id/ 是两个不同节点；另外，:id 必须是路径段（segment）级别的占位符，不能出现在查询参数位置或嵌套在子路径里（比如 /user/:id/profile 是合法的，但 /user/:id?tab=1 中的 :id 不会被识别）。
检查点包括：
-
c.Param("id")返回空字符串时，先确认请求 URL 确实是/user/123（不含查询参数干扰），且注册路由时没多写斜杠 - 使用
r.NoRoute()捕获未匹配路径，打印c.Request.Method和c.Request.URL.Path看实际进来的值 - 避免在路径中使用正则或通配符 —— Gin 原生不支持，
:id是唯一路径参数语法，*只用于通配路由（如/*filepath），且必须放在末尾
GET 查询参数和 POST 表单参数怎么安全获取？
查询参数（?key=value&key=another）用 c.Query() 或 c.DefaultQuery()，表单参数（application/x-www-form-urlencoded）用 c.PostForm()。两者底层都依赖 url.ParseQuery()，但关键区别在于：如果请求体是 JSON，c.PostForm() 会返回空，因为它不解析 JSON body。
正确做法是按 Content-Type 分流：
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- Content-Type 是
application/json→ 用c.ShouldBind(&struct{})，它会自动选择 JSON 解析器 - Content-Type 是
multipart/form-data（含文件）→ 先用c.FormFile()拿文件，再用c.PostForm()拿其他字段 - 不确定类型又想兜底 →
c.ShouldBind()比c.GetRawData()+ 手动解析更安全，它内置了 MIME 类型判断和错误处理
路由分组（Group）为什么中间件不生效？
常见错觉是 r.Group("/api") 自动继承父级中间件，其实不会 —— Group 创建的是新 RouterGroup 实例，中间件必须显式传入或在 group 内部调用 Use()。例如：
r := gin.Default() // 自带 logger & recover
v1 := r.Group("/api/v1")
v1.Use(authMiddleware) // 必须手动加，否则 authMiddleware 不会跑
v1.GET("/user", handler)
另一个坑是中间件顺序：Group 上 Use() 的中间件，在该 group 下所有路由 handler 执行前依次运行；但如果在 group 外又调用了 r.Use()，那个中间件对 group 内路由无效 —— 因为 r 和 v1 是不同作用域。
调试建议：
- 在中间件里加日志，输出
c.Request.URL.Path，确认是否真被调用 - 避免在 group 定义后、路由注册前漏掉
Use()调用 - 不要把
c.Next()忘在中间件里，否则后续 handler 不会执行
基数树匹配快，但路径定义一旦写死就难动态调整；:param 和 *wildcard 语义差异大，用错一个字符就断在 404；中间件链和 group 作用域容易误判，最好每次加新路由时，用 r.NoMethod() 和 r.NoRoute() 捕获异常路径并打日志 —— 这些不是边缘情况，而是上线后最常暴露问题的地方。
