c.next()是索引推进而非递归调用，中间件链条本质为handlerschain切片遍历；注册时通过append将中间件追加到group.handlers，combinehandlers合并全局与局部中间件及handler形成最终切片，请求时由context.index控制执行位置。
c.Next() 不是递归调用，而是链式跳转；中间件链条本质是切片遍历 + 索引推进，不是函数栈嵌套。
中间件注册时发生了什么：HandlersChain 是个切片，不是调用栈
Gin 中所有中间件（包括最终的 handler 函数）最终都存进 HandlersChain 类型的切片里，类型定义为 []HandlerFunc。注册顺序直接决定执行顺序：
-
r.Use(m1, m2)→ 全局中间件列表变为[m1, m2] -
r.GET("/api", m3, handler)→ 该路由的 handlers 变为[m1, m2, m3, handler]（combineHandlers合并了全局 + 局部） - 这个切片在请求到达时被整体传入
engine.handleHTTPRequest，后续靠Context.index字段控制执行位置
c.Next() 的真实行为：索引+1 后继续循环，不是函数调用
每次调用 c.Next()，实际只是把 c.index 加 1，然后回到当前 handler 所在循环的下一轮 —— 它不 push 新栈帧，也不 require return 后自动回溯。
- 初始
c.index = -1，第一次c.Next()→c.index = 0→ 执行handlers[0] - 在
m1里调用c.Next()→c.index = 1→ 跳到m2开头 - 若
m2内没再调c.Next()，则c.index停在 1，后续 handler 不会执行 -
c.Abort()是直接把c.index设为len(handlers)，强制跳出循环
为什么容易误以为是递归：日志输出顺序造成的错觉
看这段典型代码：
func m1(c *gin.Context) {
log.Println("m1 before")
c.Next()
log.Println("m1 after")
}
func m2(c *gin.Context) {
log.Println("m2 before")
c.Next()
log.Println("m2 after")
}
输出是：
m1 before m2 before m2 after m1 after
这看起来像“进入 m1 → 进入 m2 → 退出 m2 → 退出 m1”，但实际是：
-
m1执行到c.Next()，暂停自身，推进 index，跳去执行m2 -
m2执行完全部逻辑（含自己的c.Next()和后续代码），返回到m1暂停点 - 所以“after”部分的执行顺序，取决于各中间件中
c.Next()的位置和是否被跳过
真正影响执行流的关键：c.index 和 handlers 切片长度
整个链条的可控性完全依赖这两个值。常见陷阱包括：
- 在中间件里漏写
c.Next()→ 后续所有 handler 都不会执行（包括最终业务函数） - 在
c.Next()后还写了业务逻辑，但前面中间件调了c.Abort()→ 这段代码永远不会运行 - 用
c.Set()传数据没问题，但若在c.Next()前 set、在c.Next()后 get，必须确保 index 推进到了能 get 的位置 - 静态文件路由（如
r.Static()）也会走同一套 handlers 链，所以全局中间件默认对 404/静态资源生效 —— 若不希望日志打满，得用g.Group().Use()隔离
链条本身没有隐式状态，所有控制都暴露在 c.index 和切片边界上；理解这点，才能避开“为什么 after 没打印”“为什么 handler 没触发”这类问题。
