gin.Default() 初始化了三件事：注册Logger和Recovery中间件、初始化sync.Pool复用*gin.Context、构建空methodTrees路由树，直接影响性能与安全性。
gin.Default() 初始化了什么
它不是简单地 new 一个 Engine，而是做了三件关键事：注册默认中间件（Logger() 和 Recovery()）、初始化 sync.Pool 用于复用 *gin.Context、构建空的 methodTrees 路由树。这三点直接决定后续请求的性能与安全性。
常见错误是以为 Default() 只是“开箱即用”，结果在生产环境漏掉 Recovery 导致 panic 泄露堆栈；或误以为没注册中间件就等于“无日志”，其实 Logger() 已悄悄写入标准输出。
如果你需要完全干净的引擎（比如做协议代理或嵌入式 HTTP 处理），应该用 gin.New()，再按需添加中间件。
Context 对象池复用的真实代价
Engine.pool 确实减少了 GC 压力，但它的复用逻辑有隐含约束：每次请求结束后，Context 的所有字段（包括 Keys map、Errors slice、Writer 等）都会被显式重置。这意味着你不能在中间件里缓存任何跨请求的数据到 c.Keys 中——下一次请求会把它清空。
立即学习“go语言免费学习笔记（深入）”；
容易踩的坑：
- 在中间件中调用
c.Set("user_id", id)后，期望后续 handler 能读取，没问题；但若在 handler 中又写入新 key，该 key 不会残留到下次请求 —— 这是设计使然，不是 bug - 自定义
ResponseWriter实现时，如果依赖Context.writer的初始状态（如 status=0），要注意它可能已被上一轮请求改写过，必须在Reset()阶段彻底清理 -
sync.Pool.Get()返回的对象不保证是零值，Gin 在engine.allocateContext()里做了字段级清空，但如果你扩展了Context结构体，必须同步修改重置逻辑
Radix 树路由匹配为何不支持正则
Gin 的 tree.go 实现的 Radix 树只处理静态路径、参数占位符（:id）和通配符（*filepath），所有匹配都在 O(k) 时间内完成（k 是路径段数）。它刻意避开正则，因为正则编译和回溯匹配会破坏确定性时间复杂度，也难以做前缀剪枝优化。
使用场景限制很明确：
- 路径
/user/:id→ 匹配/user/123，c.Param("id")取得"123" - 路径
/file/*filepath→ 匹配/file/a/b/c.txt，c.Param("filepath")是"a/b/c.txt" - 想匹配
/api/v[1-3]/users？不行。必须拆成/api/v1/users、/api/v2/users、/api/v3/users三条静态路由，或用中间件提前解析版本号
这不是功能缺失，而是性能取舍。一旦引入正则，路由树就退化为线性扫描，40 倍性能优势瞬间归零。
中间件链执行时 Abort() 的实际行为
c.Abort() 并不终止 Goroutine，它只是把 c.index 设为 abortIndex（即 -1），让后续 Next() 调用直接返回，跳过剩余中间件和 handler。但当前中间件函数体仍会继续执行完。
典型误用：
- 在鉴权中间件里写
if !valid { c.Abort(); return }—— 正确；但如果漏掉return，后续代码（比如日志记录、DB 查询）仍会执行 - 在中间件中调用
c.AbortWithStatusJSON(401, ...)后，忘记return，导致响应头被多次写入，触发http: superfluous response.WriteHeader call错误 -
Abort()不影响已写入的响应体，但会阻止后续中间件修改ResponseWriter，所以Logger中间件看到的状态码可能是 200，而实际返回的是 401（因为Recovery或自定义中间件提前写了响应）
最易被忽略的一点：Abort() 只对当前请求的中间件链生效，不影响其他并发请求；但它改变的是 *gin.Context 实例本身的状态，所以绝不能在 Goroutine 中调用 —— 必须用 c.Copy() 后再调用。
