engine 是每次请求时被 http.listenandserve 调用 servehttp 的 handler 实例，实现 net/http.handler 接口，依赖 trees（字典树路由）、pool（context 复用）和 handlers（中间件链）三者驱动，纯同步处理，无后台 goroutine。
Engine 不是“启动后就一直跑着”的黑盒，它是每次请求进来时被 http.ListenAndServe 调用一次 ServeHTTP 方法的 Handler 实例，核心动作发生在请求抵达瞬间。
Engine 实现了 net/http.Handler 接口
这是 Gin 能和标准库对接的根本前提。你传给 http.ListenAndServe(":8080", r) 的 r（即 gin.Default() 返回值），必须满足 func(http.ResponseWriter, *http.Request) 签名——Engine.ServeHTTP 正是这个实现。
它不自己监听端口，也不轮询连接；只是被动响应：连接建立 → 标准库解析请求 → 调用你的 Engine.ServeHTTP → Gin 开始路由匹配和中间件链执行。
-
Engine内部没有 goroutine 循环或长任务，纯同步处理单个请求 - 若你在
ServeHTTP里加了log.Println("hit")，每来一个请求就会打一行，而不是启动时打一次 - 错误如
panic默认由Recovery()捕获并返回 500，前提是用了gin.Default()；gin.New()不带该中间件，panic 会直接崩溃进程
Engine.pool 是 context 复用的关键
Engine.pool 是一个 sync.Pool，用来复用 *gin.Context 实例。每次请求进来，ServeHTTP 第一步就是 c := engine.pool.Get().(*Context)，而不是 &Context{} 新建。
这直接降低 GC 压力，尤其在高并发场景下效果明显。但要注意：
- 复用意味着你不能在中间件或 handler 里长期持有
*gin.Context指针（比如塞进 goroutine 或 map），否则可能被后续请求覆盖字段 -
Context的Reset()方法会在每次取出后自动调用，清空上一次的Request、Writer、params等字段，所以你无需手动初始化 - 如果你写了自定义中间件并修改了
c.Keys或c.Set()，这些数据只对当前请求生命周期有效，不会污染下一次
Engine.trees 存的是压缩后的 methodTree 字典树
所有 GET、POST 等路由不是存在 map 里线性查找的，而是按 HTTP 方法分组存进 Engine.trees（类型为 methodTrees），每个方法对应一棵前缀压缩字典树（类似 trie，但支持 :id 和 *wildcard）。
例如注册 r.GET("/api/v1/users/:id", handler)，实际会把路径拆成 ["api", "v1", "users", ":id"] 插入 GET 对应的树中。匹配时从根节点逐段比对，遇到 :id 就捕获参数值。
- 静态路径（如
/health）匹配最快，O(1) 到 O(len(path)) - 带通配符的路径（如
/static/*filepath）需要回溯，性能略低，但仍是常数级 - 重复注册相同 path+method 会 panic，Gin 在
addRoute阶段就检查冲突，不是运行时才发现 -
RemoveExtraSlash: true（默认开启）会让/a//b自动转成/a/b再匹配，避免因前端多斜杠导致 404
Engine.Use() 注册的是 handlersChain 全局链
Engine.Use(middleware...HandlerFunc) 把中间件追加到 Engine.Handlers（类型为 HandlersChain），这个链会在每个路由匹配成功后、执行业务 handler 前统一串行执行。
注意它和 RouterGroup.Use() 的区别：
-
Engine.Use()影响所有路由，包括子 group；它是全局中间件入口 -
group.Use()只影响该 group 下注册的路由，且会与 Engine 的链合并（group 的链在前，Engine 的链在后） - 中间件函数签名必须是
func(*gin.Context)，且必须显式调用c.Next()才能继续执行后续 handler；漏掉c.Next()就会中断链路 - 如果中间件里调用了
c.Abort()，后续所有 handler（包括业务 handler）都会跳过，但已执行的中间件不会回滚
真正容易被忽略的点在于：Engine 的行为完全由它持有的 trees、pool、handlers 三者驱动，没有隐藏状态或后台协程；它的“高性能”来自字典树匹配 + context 复用 + 同步无锁设计，而不是靠异步或复杂调度——这也意味着，一旦你在 handler 里阻塞（比如死循环、长时间 IO 未加超时），整个 goroutine 就卡住，直接影响吞吐。
