gin中间件执行由c.next()和c.index控制，c.next()递增c.index并调用下一个handler，abort()仅跳过后续handler但不重置c.index，需用c.isaborted()判断阻止后置逻辑。
Gin 的中间件不是黑盒，它的执行逻辑完全由 c.Next() 和 c.index 控制，不理解这点就容易误用 Abort() 或写错前后置逻辑顺序。
中间件函数本质就是 gin.HandlerFunc
它只是一个接受 *gin.Context 的函数类型：
type HandlerFunc func(*Context)
没有特殊语法糖，也不需要实现接口。你写的路由处理函数（比如 r.GET("/ping", func(c *gin.Context){...})）本身也是 HandlerFunc，和中间件完全同构。
关键区别在于：中间件里必须显式调用 c.Next() 才会进入下一个环节；而路由处理函数是链的终点，调用完就结束了。
- 所有中间件和最终 handler 都被存进
c.handlers切片，按注册顺序排列 -
c.index是当前执行到第几个 handler 的游标，初始为 -1 -
c.Next()会先c.index++，再执行c.handlers[c.index](c)
c.Next() 不是“继续往下走”，而是“递归进入下一层”
洋葱模型不是靠栈帧自动回溯，而是靠 c.Next() 显式触发下一级，并在返回后继续执行当前函数剩余代码。看这个典型日志中间件：
func Logging() gin.HandlerFunc {
return func(c *gin.Context) {
log.Println("→ before")
c.Next() // 这里跳转：可能进 Auth → 进 DB → 进业务 handler
log.Println("← after") // 所有后续 handler 全跑完才执行这行
}
}
如果你在 c.Next() 后面加了状态判断（比如 if c.Writer.Status() == 401），那它看到的一定是最终响应状态，不是中间某步的状态。
- 错误地把
c.Next()当作“让流程继续”来用，会导致后置逻辑永远不执行 - 忘记中间件里也要写
c.Next()，整个链就卡死在这一层 - 多个中间件嵌套时，
c.index是共享的，所以不能靠它做条件跳过
全局中间件 vs 路由级中间件，注册时机决定作用域
r.Use(...) 注册的是全局中间件，影响所有路由；而 r.GET("/path", m1, m2, handler) 中传入的中间件只对这个路由生效。
注意：r.Group("/api").Use(Auth()) 注册的中间件，只对 group 内的子路由起作用，且会叠加在全局中间件之后、路由 handler 之前。
-
gin.Default()实际等价于gin.New().Use(Logger(), Recovery()) - 用
gin.New()启动时，不带任何中间件，panic 会直接崩溃进程 - 路由级中间件注册顺序严格从左到右，
r.GET("/x", A(), B(), C())意味着 A → B → C → handler
c.Abort() 会跳过后续所有 handler，但不会重置 c.index
这是最容易踩坑的地方：c.Abort() 只是把 c.index 设为 int8(len(c.handlers))，让 c.Next() 不再执行任何 handler，但它不会“倒退”或“清空已执行的中间件”。
比如你在 Auth 中间件里 c.Abort() 返回 401，那 Logging 中间件里的 log.Println("← after") 依然会执行——因为它的 c.Next() 已经调完了，只是后续没再进新 handler。
- 想阻止后置逻辑执行？得自己加 flag 或用
c.IsAborted()判断 -
c.AbortWithStatusJSON(401, ...)是封装好的常用组合，但底层仍是Abort()+JSON() - 跨中间件传数据用
c.Set("key", val)，但要注意生命周期：只要c活着，数据就在
真正难的不是写中间件，而是预判 c.index 在哪一步、c.Next() 会跳去哪、c.Abort() 后谁还会执行——这些都得对着 handler 切片和 index 变量 mentally trace 一遍。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
