c.handlers切片与c.index游标共同驱动Gin中间件链执行：c.index从-1开始，每次c.Next()先自增再调用c.handlers[c.index](c)；漏写c.Next()则链路卡死，误用c.index做条件判断会因全局递增而失效；c.Abort()仅将c.index设为最大值以阻断后续调用，不重置游标。
c.handlers 切片和 c.index 游标是执行核心
中间件链不是靠函数调用栈自动回溯，而是靠 c.handlers 切片 + c.index 游标显式推进。所有注册的中间件和最终 handler 都被扁平化存进 c.handlers，c.index 从 -1 开始，每次 c.Next() 先自增再调用 c.handlers[c.index](c)。
常见错误现象：在中间件里漏写 c.Next()，整个链就卡死，后续 handler 完全不执行；或者误以为 c.index 是“当前层编号”，拿它做条件跳过（比如 if c.index == 2 { ... }），但其实它是全局共享游标，多层嵌套时值会持续递增，不可靠。
关键点：
-
c.handlers在路由注册时就已合并完成（全局中间件 + group 中间件 + 路由 handler） -
c.index是 *gin.Context 实例的字段，每个请求独享一份，不会跨请求污染 - 调用
c.Abort()只是把c.index设为int8(len(c.handlers))，让后续c.Next()不再触发新 handler，但不会重置或回退游标
为什么 c.Next() 不是“继续”，而是“递归进入下一层”
c.Next() 的行为常被误解为“让流程往下走”，实际它是一次显式的、带控制权移交的函数调用：先 c.index++，再执行 c.handlers[c.index](c)。这个调用可能进入另一个中间件，也可能直接落到业务 handler 上。
洋葱模型的“回溯”不是靠 return 自动发生，而是靠每个中间件在 c.Next() 返回后，继续执行自己 c.Next() 后面的代码——也就是后置逻辑。
典型陷阱：
- 在
c.Next()后加状态判断（如if c.Writer.Status() == 401），看到的一定是最终响应状态，不是中间某步的状态 - 在多个中间件里都写
defer日志，结果日志顺序混乱，因为 defer 是按函数退出顺序执行，而中间件执行是深度优先 - 用
return替代c.Abort()，会导致当前中间件提前退出，但后续中间件仍可能被执行（因为c.index没被封禁）
全局 Use()、Group().Use()、路由内传参的区别在哪
三者注册时机不同，直接影响 c.handlers 的拼接顺序，最终决定执行时的排列位置。
假设注册顺序是：
-
r.Use(A)（全局） api := r.Group("/api").Use(B)api.GET("/user", C, D, handler)
那么该路由的 c.handlers 切片内容就是：[A, B, C, D, handler]。注意：B 是 group 级中间件，只对 /api 下所有子路由生效，且一定插在全局中间件之后、路由级中间件之前。
容易踩的坑：
-
r.Group("/v1").Use(Auth)和r.Use(Auth)看似一样，但前者只影响/v1下路由，后者影响全部；若同时存在，Auth会被注册两次，顺序取决于调用先后 - 路由内传参（如
r.GET("/x", M1, M2, h)）的中间件只对该路由有效，且优先级最高，永远在最右端 -
gin.Default()等价于gin.New().Use(Logger(), Recovery())，如果你手动调gin.New()却忘了加 Recovery，panic 会直接暴露给客户端
Abort() 和 IsAborted() 必须配对使用
c.Abort() 本身不返回值，也不抛异常，只是修改 c.index 并标记已中断。真正需要判断是否已被中断的地方，必须显式调用 c.IsAborted()。
比如 JWT 鉴权中间件里，验证失败后调 c.AbortWithStatusJSON(401, ...)，但后续中间件如果还试图读取用户信息，就得先 if c.IsAborted() { return }，否则可能 panic 或逻辑错乱。
性能提示：
-
c.IsAborted()是个简单布尔判断，开销可忽略，但漏判会导致严重逻辑错误 - 不要在中间件开头无条件调
c.Abort()再手动写响应，除非你明确不需要后续任何中间件参与（包括 Logger、Recovery） - 多个中间件共用同一份上下文数据（如
c.Set("user", u)），一旦前面中间件Abort()，后面中间件再c.Get("user")就会拿到 nil，需配合c.IsAborted()做防御
真正难的不是写中间件函数，而是理解 c.index 如何被所有中间件共享、c.Next() 如何精确控制执行流、以及 Abort() 后如何安全地跳过依赖逻辑。这些细节不摸透，调试时就会陷入“为什么这行日志没打出来”“为什么状态码不对”这类问题。
