中间件函数签名必须是func(*gin.context)，因为gin通过该统一签名实现类型推断和链式调用；所有中间件最终存入handlerschain（[]gin.handlerfunc），而gin.handlerfunc即此签名的别名，其他签名会导致编译错误。
中间件函数签名和执行模型为什么必须是 func(*gin.Context)
因为 Gin 的整个中间件链依赖这个统一签名做类型推断和顺序调用。所有中间件最终都会被追加进 HandlersChain（本质是 []gin.HandlerFunc），而 gin.HandlerFunc 就是 func(*gin.Context) 的别名。一旦你写成 func(http.ResponseWriter, *http.Request) 或带返回值，就无法被 Use() 接收，编译直接报错。
洋葱模型不是语法糖，而是靠 c.index 控制的执行游标：每次调用 c.Next() 时，c.index 自增，跳到下一个 HandlerFunc；响应阶段再倒序执行已进入但未退出的中间件后半段。所以中间件里漏写 c.Next()，后续所有中间件和路由处理器都不会执行。
-
c.Next()不是“建议调用”，而是流程推进的唯一开关 - 中间件中若提前
c.Abort()，c.index会被设为最大值，彻底跳过剩余链路 - 多个中间件共享同一个
*gin.Context实例，c.Set("key", val)写入的数据能被后续中间件或 handler 用c.Get("key")读到
中间件注册顺序如何影响实际执行逻辑
注册顺序 = 请求进入时的前置执行顺序，也决定了响应返回时的后置执行逆序。比如：
r := gin.New()
r.Use(A, B, C)
r.GET("/user", handler)
请求进来时执行顺序是 A→B→C→handler；响应出去时是 handler→C（后半段）→B（后半段）→A（后半段）。这点在日志、耗时统计、Header 设置等场景特别关键。
- 如果
CORS中间件放在Recovery后面，panic 导致的 500 响应可能没带上Access-Control-Allow-Origin头，前端拿不到跨域响应 - 认证中间件必须在业务 handler 前注册，否则
c.Get("user_id")拿不到值 - 全局
Logger放最前，才能记录完整生命周期；Recovery放最后，才能兜住所有 panic
c.Next() 和 c.Abort() 的行为差异到底在哪
两者都改变 c.index，但语义和后果完全不同。
c.Next() 是推进指针：当前中间件暂停，让出控制权给下一个 handler；等它执行完再回来继续跑当前中间件的后半段代码。适合日志、计时、Header 注入这类“包裹式”逻辑。
c.Abort() 是终止指针：把 c.index 设为 len(c.handlers)，后续所有中间件和 handler 都被跳过。常用于权限拦截、参数校验失败等需立即响应的场景。
- 错误示范：在认证失败时只
c.JSON(401, ...)但不c.Abort()→ handler 仍会执行，可能造成越权访问 - 正确做法：
c.AbortWithStatusJSON(401, gin.H{"msg": "token invalid"})，内部已封装c.Abort() - 注意：
c.Abort()后不能再调用c.Next()，否则 panic
为什么自定义中间件要避免闭包捕获外部变量
闭包捕获的变量在中间件注册时就确定了，不会随每次请求更新。比如下面这段代码：
var count int
r.Use(func(c *gin.Context) {
count++
c.Set("req_id", count)
c.Next()
})
看起来像在计数，实际 count 是全局变量，所有请求共享，高并发下会错乱且不可预测。更隐蔽的问题是，如果闭包捕获了数据库连接、配置对象等非线程安全资源，也会引发竞态。
- 正确方式：所有状态应绑定到
*gin.Context上，如c.Set("user", user) - 需要累积状态（如请求计数）请用原子操作或 sync.Map，而不是普通变量
- 中间件函数体本身是无状态的，它的“状态”只该来自
c或传入的配置结构体（如cors.Config）
