Gin路由比标准库快因采用Radix树实现O(k)匹配，而net/http.ServeMux为O(n)顺序遍历；Gin自动拆分路径段并复用节点，支持:id和*filepath语法，注册顺序不影响匹配。
为什么 Gin 的路由比标准库快那么多
因为 Gin 不用正则匹配，而是用 Radix 树（压缩前缀树）做路径查找，时间复杂度接近 O(1)。标准库 net/http 的 ServeMux 是顺序遍历，遇到上百条路由时性能明显下降；Gin 在注册 GET("/user/:id")、GET("/user/:id/orders") 时会自动拆段、复用节点，避免重复解析。
常见错误现象：把动态参数写成 "/user/{id}" 或 "/user/*id" —— Gin 只认 :id 和 *filepath 两种语法，其他写法会导致 404。
-
:param匹配单段（如/user/123中的123），不可跨斜杠 -
*filepath匹配多段（如/static/js/app.js整个路径），必须放在末尾 - 路由注册顺序不影响匹配结果，Radix 树构建后就固化了，和注册先后无关
中间件执行顺序不是“从上到下”，而是“洋葱模型”
你写 engine.Use(m1, m2)，再写 router.GET("/api", handler)，实际执行流是：m1 前置 → m2 前置 → handler → m2 后置 → m1 后置。关键在 c.Next()：它不是“调用下一个”，而是“让控制权往下走，等回来再继续执行后面代码”。
容易踩的坑：在 c.Next() 之后读取 c.Writer.Status() 或 c.Writer.Size() 时发现是 0 —— 因为响应还没真正写出，c.Writer 是个 wrapper，真实写入发生在整个链结束时。需要用 c.Writer.StatusWritten 判断是否已发头。
立即学习“go语言免费学习笔记（深入）”；
- 全局中间件用
engine.Use()，只对engine启动后的所有路由生效 - 路由组中间件用
group.Use()，优先级高于全局中间件（即更靠近 handler） - 想跳过后续中间件？用
c.Abort()；想终止并返回错误？用c.AbortWithStatusJSON()
自定义中间件里怎么安全地存取数据
gin.Context 提供 c.Set(key, value) 和 c.Get(key)，但 key 类型必须是 interface{}。直接传字符串当 key 看似方便，实际极易冲突——比如两个中间件都用 "user_id"，后者会覆盖前者。
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
正确做法是定义私有类型作 key：
type userIDKey struct{}
func authMiddleware() gin.HandlerFunc {
return func(c *gin.Context) {
id := extractUserID(c)
c.Set(userIDKey{}, id) // 不是 "user_id"
}
}
// 取值时也用同一类型
if id, ok := c.Get(userIDKey{}).(int64); ok { ... }
性能影响：每次 c.Set 都是 map 写入，但 sync.Map 底层做了优化；频繁存取建议用结构体字段（如 c.Set("req_meta", &meta{})）而不是大量独立 key。
panic 恢复中间件为什么不能只靠 recover()
Gin 内置的 gin.Recovery() 确实调用了 recover()，但它还做了三件事：记录 panic 堆栈、重置 Writer 状态、强制返回 500。如果自己手写 recovery，漏掉任何一项都会导致后续请求异常——比如没重置 Writer，下个请求可能拿到上一个 panic 时残留的 header。
最常被忽略的点：panic 可能发生在 c.Next() 之后的后置逻辑里，此时 recover() 依然有效，但很多自定义中间件只在前置部分 defer recover，漏掉了后置部分。
建议直接用 gin.Default() 启动（自带 Logger() + Recovery()），或明确调用 engine.Use(gin.Recovery())，别自己重造轮子。
