Gin 的 *gin.Context 实例由 sync.Pool 自动管理，绑定单次请求，不可手动创建或跨 goroutine 传递；c.Next() 和 c.Abort() 通过操控 index 控制中间件流程，须在同步调用栈内使用；参数绑定方法默认自动 Abort，Context.Keys 是唯一安全的中间件通信方式。
Gin 的接口生命周期不是由开发者手动控制的，而是由 *gin.Context 实例自动承载并严格限定在单次 HTTP 请求内——它一创建就绑定请求，一返回就销毁，不存在跨请求复用或手动释放的问题。
Context 实例从哪来、到哪去？
每次 HTTP 请求到达时，Gin 从内部 sync.Pool 中取出一个预分配的 *gin.Context 实例（避免频繁 GC），填充 Request、Writer、handlers 等字段后传入中间件链和最终 handler。请求结束（无论成功或 panic）、响应写出后，该实例被清空并归还池中。
- 你不能 new 出 Context：没有公开构造函数，
engine.allocateContext()是私有方法 - 你不该保存 Context 指针：它只在当前 goroutine 中有效，跨 goroutine 传递会导致数据竞争或 panic
- 不要试图“复用” Context：Pool 已经做了这件事；手动缓存只会污染状态（比如残留的
Keys、Errors）
为什么 c.Next() 和 c.Abort() 行为容易误判？
这两个方法直接操控 Context.index 字段，决定中间件链的执行流程，但它们的效果依赖于调用时机和上下文所处的 handler 链位置。
-
c.Next()：暂停当前 handler，执行后续 handler（包括下一个中间件或最终 handler），再回到当前 handler 继续执行——常用于日志记录“前后”逻辑 -
c.Abort()：将c.index设为abortIndex（-1），跳过剩余所有 handler，但已执行过的中间件仍会继续向下返回（洋葱模型外层仍运行） - 常见错误：在异步 goroutine 中调用
c.Abort()—— 此时c已离开原始执行栈，index修改无效，且可能引发 panic - 正确做法：所有
Abort/Next必须在当前 handler 的同步调用栈内完成
参数解析、绑定与错误终止必须成对出现
Gin 的参数提取（c.Query、c.Param）本身不触发终止，但绑定类方法（c.ShouldBindJSON、c.Bind）默认会在失败时调用 c.Abort() 并写入 400 响应——这个隐式终止行为常被忽略。
立即学习“go语言免费学习笔记（深入）”；
-
c.ShouldBindJSON(&v)：失败时自动Abort()+JSON(400, ...)，你无需也不该再手动c.JSON -
c.BindJSON(&v)：同上，但 panic 时会触发 Recovery 中间件（如果启用） -
c.GetBool("key")这类取值方法不会 abort，但返回零值，需自行判断是否继续 - 想自定义错误响应？用
c.Bind替代c.ShouldBind，然后手动检查 error 并决定是否c.Abort()
Context.Keys 是唯一安全的中间件通信方式
多个中间件之间传递数据，只能通过 c.Keys（map[any]any），其他字段如 c.Request.Context() 或全局变量都不可靠。
-
c.Set("user_id", 123)和c.GetInt64("user_id")是标准用法，类型安全且作用域明确 - 不要往
c.Request.Context()里塞数据：虽然能 work，但违反 Gin 设计契约，且Request.Context()可能被底层 net/http 或其他中间件覆盖 - 避免用字符串字面量作 key：推荐定义 const key = "user_info"，防止拼写错误
-
c.Keys不是线程安全的：它只在当前请求 goroutine 内使用，无需额外加锁
真正容易被忽略的是 Context 的“一次性”本质：它不提供任何延迟清理钩子（比如 defer 无法跨 handler 生效），所有资源（DB 连接、文件句柄、goroutine）必须在 handler 返回前显式释放——Gin 不会替你收尾。
