因为Engine实现了http.Handler接口的ServeHTTP方法，故可直接传给http.ListenAndServe；它不监听连接，仅将http.Request和http.ResponseWriter转为gin.Context并交由路由树分发。
gin.Engine 为什么能直接传给 http.ListenAndServe
因为 Engine 实现了 http.Handler 接口的 ServeHTTP 方法。这是 Gin 能“无缝接入”标准库的底层前提。
你写 r := gin.Default(); http.ListenAndServe(":8080", r) 或 r.Run()，本质都是把 Engine 当作 handler 交给 Go 原生 HTTP server。关键就在 Engine.ServeHTTP 这个方法里——它不自己监听，只负责分发请求。
-
Engine.ServeHTTP会从sync.Pool取出一个复用的*gin.Context，避免频繁分配内存 - 根据
req.Method找到对应 methodTree（比如GET树或POST树） - 用 Radix 树做路径匹配，找到注册的 handler 和中间件链（
HandlersChain） - 把 handler 和中间件塞进
Context.handlers，再调用c.Next()启动执行链
Radix 树路由匹配是怎么跳过无效路径的
Gin 不是逐字符比对，也不是正则回溯，而是靠前缀共享节点 + 显式通配符标记来加速。比如注册了 /api/v1/users/:id 和 /api/v1/orders，它们共用 /api/v1/ 节点，但 :id 是一个带标记的 wildcard 节点，不是普通子节点。
匹配时，引擎会沿树向下走，遇到 : 开头的 segment 就切换为“捕获模式”，把后续路径段赋给 c.Param("id")；遇到 * 开头（如 /*filepath）则进入“贪婪匹配”分支。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 静态路径（如
/ping）匹配最快，O(log n) 级别 - 带
:param的路径多一次字符串切分，但不回溯 - 带
*wildcard的路径需额外判断是否为最长匹配，有轻微开销 - 所有匹配逻辑都在
tree.getValue中，不依赖反射或正则
中间件执行链 c.Next() 的 index 控制容易出什么错
c.Next() 看似简单，实则是 Gin 请求生命周期的节拍器。它的行为完全由 c.index 控制：初始为 -1，每次调用 Next 就 +1，直到等于 len(c.handlers) 才停止。
常见误用导致请求卡住或跳过 handler：
- 在中间件里忘了调用
c.Next()→ 后续中间件和最终 handler 永远不执行 - 在中间件里多次调用
c.Next()→ handler 被重复执行，可能 panic 或返回两次 - 调用
c.Abort()后又调用c.Next()→c.index已被设为 63（最大值），Next直接 return，但开发者可能误以为还能继续 - 在异步 goroutine 里调用
c.Next()→c被多个 goroutine 并发修改index，结果不可预测
Context 对象池复用带来的隐性陷阱
Engine.pool 默认用 sync.Pool 缓存 *gin.Context，大幅降低 GC 压力。但这也意味着：每个 Context 实例不是全新创建的，其字段可能残留上一次请求的数据。
最典型的问题是 c.Set("key", value) 后没清理，下个请求读 c.MustGet("key") 拿到的是旧值。
-
Context的Keys、Errors、Params、Accepted等字段都可能残留 - Gin 在
engine.handleHTTPRequest开头会重置c.index = -1和c.writermem.reset()，但不会清空c.Keys - 安全做法是：只在明确生命周期内使用
Set/Get，或手动delete(c.Keys, "key")；敏感数据（如用户 ID）建议用局部变量传参，而非塞进 Context - 如果启用了
ContextWithFallback，还要注意c.Request和c.Writer也可能被复用，不能假设它们为空
sync.Pool 决定内存压力，index 控制流决定中间件顺序，而所有这些，都压在一个 ServeHTTP 方法里调度。漏掉任意一环，线上就容易出现偶发超时、参数错乱或 panic。 
