handlerfunc 是 gin 中间件和路由处理函数的统一类型，所有注册项最终拼成 handlerschain 切片，由 context.index 控制执行顺序，c.next() 为 for 循环驱动的顺序调用而非递归。
HandlerFunc 是 Gin 中间件和路由处理函数的统一类型
所有注册到 Gin 的东西——无论是 r.Use() 添加的全局中间件、group.Use() 添加的分组中间件，还是 r.GET() 绑定的业务 handler——最终都会被转成 HandlerFunc 类型，并按顺序拼成一个切片：HandlersChain。这个切片就是整个请求链的“执行列表”。
它不是链表也不是闭包嵌套，就是一个普通数组，靠 Context.index 当前下标来控制执行进度。
-
Context.index初始化为 -1，第一次调用c.Next()时自增为 0，执行handlers[0] - 每个
HandlerFunc内部若调用c.Next()，就继续推进下标，执行下一个 - 不调用
c.Next()，下标卡住，后续所有 handler 都不会被执行 -
c.Abort()直接把index设为len(handlers)，彻底跳过剩余环节
c.Next() 不是递归，而是 for 循环驱动的顺序调用
Gin 的 c.Next() 实现非常直白：它内部是个 for 循环，从当前 index + 1 开始，一路调用到切片末尾。这不是函数调用栈意义上的“递归”，也没有隐式堆栈展开。
这意味着：如果你在中间件里手动多次调用 c.Next()，会导致 handler 被重复执行；而如果忘了调用，流程就断在那儿，后面全丢弃。
- 错误写法：
if user.IsAdmin { c.Next() }; c.Next()→ 可能执行两次后续链 - 典型漏写：
if !tokenValid { c.AbortWithStatus(401); return }后没写c.Next()→ 认证失败后本该终止，但若漏了c.Abort()或没 return，后续 handler 仍可能跑 -
c.Next()返回后，代码继续往下走，可以做后置逻辑（比如日志打耗时）
中间件顺序决定洋葱模型的“层叠方向”
所谓“洋葱模型”，本质就是注册顺序 = 请求进入顺序 = 响应退出逆序。Gin 不做额外调度，完全由 HandlersChain 的拼接方式和 c.Next() 的推进逻辑决定。
比如：r.Use(A, B); r.GET("/x", C)，实际链是 [A, B, C]。请求流：A→B→C→B→A；响应流是原路返回，不是新起一轮。
- 日志中间件放最外层（
r.Use(Logger)），才能包住所有路由 - 认证中间件必须在业务 handler 前，否则
c.Get("user")拿不到值 - Recovery 中间件要放在靠后位置，才能捕获前面所有中间件 panic
- 注意 group 级
Use()和路由级 handler 的合并时机：是在handle()里用group.combineHandlers()拼起来的，不是运行时动态查
HandlersChain 的拼接发生在路由注册阶段，不是请求时
很多人误以为每次请求都重新组装中间件链。实际上，HandlersChain 是在你调用 r.GET()、group.POST() 这类方法时，就已把当前 group 的 Handlers 和传入的 handler 合并好，存进路由树的 node.handlers 里了。
也就是说：请求来了之后，engine.handleHTTPRequest() 直接取出预计算好的 handlers 切片，塞给 Context，然后调 c.Next() 开干。没有反射、没有闭包重建、没有运行时查找。
- 好处：极致轻量，零分配（除 Context 本身）
- 坑点：中间件函数不能依赖闭包捕获的局部变量，除非你明确知道它的生命周期（比如配置在初始化时传入）
- 调试技巧：打印
c.handlers长度或遍历看函数名，能快速确认某条路由实际绑定了哪些 handler
Context 是复用的（来自 sync.Pool），而 index 是它身上的字段。一旦某个中间件 panic 且没被 Recovery 捕获，index 可能停留在中间状态；下次从 pool 取出这个 Context 复用时，如果不重置 index，就会出错——但 Gin 在每次请求开始前已强制重置了 index = -1，所以你一般不用操心这点。
