中间件函数签名必须是 gin.HandlerFunc，因为 Gin 路由执行器只接受该类型（即 func(*gin.Context)），所有中间件需存入 HandlersChain 切片统一调度；类型不符、漏 return、未包装匿名函数等均导致编译错误。
中间件函数签名为什么必须是 gin.HandlerFunc
因为 Gin 的路由执行器只认 gin.HandlerFunc 类型——它本质是 func(*gin.Context)，而所有中间件最终都要被塞进 HandlersChain 切片里统一调度。如果你写成 func(http.ResponseWriter, *http.Request) 或 func()，编译直接报错：cannot use myMw as type gin.HandlerFunc。
常见错误现象：
- 把标准库中间件（如
loggingMiddleware(http.Handler) http.Handler）直接传给r.Use()—— 类型不匹配 - 手写中间件漏掉
return语句，导致返回值不是gin.HandlerFunc - 用
func(c *gin.Context) { ... }匿名函数但没包一层，当成值传入，而非函数类型
c.Next() 不是“自动往下走”，而是显式跳转到下一个 handler
c.Next() 是 Gin 中间件链执行的核心控制点，但它不是魔法：它只是把 c.index 加 1，然后调用 c.handlers[c.index](c)。这意味着：
- 如果当前中间件没调
c.Next()，后续中间件和路由处理函数就永远不会执行 - 如果调了多次
c.Next()，会越界 panic：index out of range -
c.Next()后的代码仍会执行（哪怕下游 panic），这是实现“后置处理”的唯一可靠位置
典型误用：c.Next() 放在 if authFailed 分支里，结果认证失败时没调，但也没 c.Abort()，导致后续逻辑意外执行。
立即学习“go语言免费学习笔记（深入）”；
中间件注册顺序 = 执行顺序，但洋葱模型靠的是 c.Next() 位置
Gin 的中间件按 Use() 调用顺序追加到 HandlersChain，所以 r.Use(mwA, mwB, mwC) 对应的执行链是 [mwA, mwB, mwC, routeHandler]。但“洋葱”效果取决于每个中间件内部怎么写：
-
c.Next()前的代码 → 外层到内层（请求进入方向） -
c.Next()后的代码 → 内层到外层（响应返回方向） - 日志中间件必须把耗时统计写在
c.Next()后面，否则拿不到下游耗时 - 鉴权中间件必须在
c.Next()前做校验，失败就c.Abort()，否则白鉴权
多个中间件组合时，Use() 是线性追加，不是嵌套包装
和标准库 func(http.Handler) http.Handler 那种嵌套不同，Gin 的 Use() 只是往切片末尾追加函数，不产生新 handler。所以：
-
r.Use(mwA); r.Use(mwB)等价于r.Use(mwA, mwB)，都变成[mwA, mwB, handler] - 没法像标准库那样写
m1(m2(handler))，Gin 不提供中间件高阶函数组合接口 - 想动态控制某条路由是否启用某中间件？得用
gin.RouterGroup分组，而不是改Use()参数
真正容易被忽略的点：中间件之间共享数据靠 c.Set()/c.Get()，但 c.Set() 必须在 c.Next() 前调用才能被下游读到；而 c.Next() 后设的值，上游才能读到——这个时机差一毫秒，数据就丢了。
