Gin请求处理核心流程为三步：Engine.ServeHTTP（启动器，复用Context并重置）、Context分配（sync.Pool复用决定性能下限）、Radix树匹配与中间件链执行（c.handlers由路由匹配+中间件拼接，c.Next()顺序执行）。
Gin 的请求处理不是黑箱，核心流程就三步：Engine.ServeHTTP → Context 分配 → Radix 树匹配 + 中间件链执行。跳过这三层，直接看 tree.go 或 context.go 容易断层。
Engine.ServeHTTP 是 net/http 和 Gin 的唯一交接点
你调用 r.Run(":8080")，最终走的是 http.ListenAndServe(addr, engine.Handler())。而 engine.Handler() 返回的正是实现了 http.Handler 接口的 *Engine 实例 —— 所以每个请求进来，第一站就是 (*Engine).ServeHTTP。
这个方法干了三件确定的事：
- 从
engine.pool.Get()拿一个复用的*Context，不是每次都 new - 调用
c.reset()重置字段（Request、Writer、Handlers等），避免脏数据 - 调用
c.Next()启动中间件和路由 handler 的执行链
注意：ServeHTTP 不做路由匹配，也不执行业务逻辑，它只是“启动器”。如果你在调试时卡在 ServeHTTP 却没进你的 handler，大概率是 pool 分配失败或 reset 出了 panic（比如自定义 Writer 实现有 nil 指针）。
Context 对象池复用决定性能下限
engine.pool 是 sync.Pool，其 New 字段指向 engine.allocateContext()。这个函数每次新建 *Context 时，会初始化 handlers 切片、index、Keys map 等 —— 但不会初始化 Request 或 Writer，那是 reset() 干的。
常见误区：
- 以为
sync.Pool能无限缓存：实际受 GC 影响，空闲对象可能被回收，高并发下仍会触发 new - 在中间件里把
*Context传给 goroutine 长期持有：一旦该 Context 被放回 pool，其他请求拿到后可能看到残留的Keys或未清空的Errors - 手动调用
pool.Put(c)：Gin 已在recover()和写响应后自动归还，重复放回会导致后续请求拿到未 reset 的 Context
验证是否复用生效？加一行日志到 allocateContext，压测时看输出频率远低于 QPS，说明 pool 起效。
Radix 树匹配发生在 c.Next() 内部，不是独立步骤
很多人以为“先匹配路由，再执行中间件”，其实不对。c.Next() 是个递归控制流：它按 c.index 顺序遍历 c.handlers，每执行一个 handler，就 c.index++；直到 c.index >= len(c.handlers) 才退出。
而 c.handlers 是怎么来的？在 ServeHTTP 里调用 engine.handleHTTPRequest(c) 时拼出来的 —— 它做了两件事：
- 用
engine.trees查当前 method + path，得到匹配的节点和参数（:id、*filepath等） - 把该节点的 handler 追加到全局中间件链（
engine.RouterGroup.Handlers）后面，组成完整c.handlers
所以关键点在于：tree.go 的 getValue 方法返回的不仅是 handler，还有 params 和 tsr（trailing slash redirect）标记。如果路径末尾多了一个 / 但没开启 RedirectTrailingSlash，匹配会失败，c.handlers 就是空切片，c.Next() 直接结束，最后 fallback 到 NotFound。
中间件链顺序由注册时机和 Group 嵌套共同决定
c.handlers 的顺序 = 全局中间件（engine.Use()） + 路由组中间件（group.Use()） + 当前路由 handler。
但要注意嵌套 group 的写法陷阱：
-
v1 := r.Group("/v1"); v1.Use(auth); v1.GET("/user", h)→ auth 在 h 前 -
v1 := r.Group("/v1", auth); v1.GET("/user", h)→ 效果一样，auth 还是在 h 前 -
r.Use(log); v1 := r.Group("/v1"); v1.Use(auth); v1.GET("/user", h)→ 最终顺序：log → auth → h -
r.Use(log); r.GET("/ping", h)→ log → h（没有 group，全局中间件直接生效）
最容易被忽略的是：**Abort() 只阻断当前及后续 handler，不跳出整个链**。比如你在 auth 中间件里 c.Abort() 并写 401，c.Next() 会立刻返回，但 log 中间件已经执行过了 —— 日志里仍会记下这次请求。要跳过 log，得把 log 放在 auth 后面，或者用条件判断绕过。
