c.IsAborted() 仅是读取请求中断状态的布尔标记，不控制流程；真正控制中间件链执行的是 c.index 与 c.Next() 的配合，c.Abort() 仅将 c.index 设为 abortIndex 以终止后续调用。
c.IsAborted() 不是控制中间件执行链的“开关”，而是反映当前请求是否已被中断的状态标记。 它本身不改变执行流程，真正起作用的是 c.Abort() 和 c.index 的配合机制。
中间件链靠 c.index 递增驱动，不是靠 return 或 panic
Gin 的中间件链本质是一个函数数组（HandlersChain），按顺序调用。每调用一次 c.Next()，就让 c.index 加 1，然后执行下一个 handler；当 c.index 达到数组长度时停止。
-
c.Next()是唯一推进链路的显式动作，不调它，后续中间件和最终 handler 就不会执行 -
c.Abort()并不重置c.index，只是把c.index设为abortIndex（一个常量，值为math.MaxInt8） -
c.IsAborted()内部只做一次比较：c.index >= abortIndex，返回布尔值
为什么 c.Abort() 后还能执行“后置逻辑”
常见误解是 c.Abort() 会立即跳出当前中间件函数。其实它只改 c.index，当前函数仍会继续往下跑 —— 这正是你能在 Abort() 后写日志、清理资源或设置响应头的原因。
- 错误写法：在
c.Abort()后还调c.Next()，会导致 panic（因为c.index已超界） - 正确模式：用
if c.IsAborted() { return }显式退出当前中间件函数，避免冗余逻辑 - 典型场景：鉴权中间件中，校验失败调
c.AbortWithStatus(401)，紧接着写return，否则可能误执行后续c.JSON()
c.Abort() 和 c.AbortWithStatus() 的行为差异
两者都设 c.index = abortIndex，但后者额外设置了状态码和响应体，且默认调用 c.Status() + c.Writer.WriteHeader()。
-
c.Abort()：纯粹中断链路，不发任何响应，留给后续中间件或 recovery 处理 -
c.AbortWithStatus(429)：中断链路 + 立即写入 HTTP 状态码，但**不自动写响应体**（除非你传了第二个参数） -
c.AbortWithStatusJSON(403, gin.H{"error": "forbidden"})：中断 + 设置状态码 + 写 JSON 响应体，适合网关插件快速拒绝
容易被忽略的细节：全局中间件里 c.IsAborted() 必须主动检查
全局中间件（如日志、recover）通常放在所有路由之前，但它无法预知下游是否已 Abort()。如果不检查 c.IsAborted()，就会对已被拒绝的请求重复记录或试图 recover。
- recover 中间件必须在开头加
if c.IsAborted() { return }，否则 panic 恢复逻辑可能干扰 429/401 响应 - 日志中间件应在结尾判断：
if !c.IsAborted() { log.Info("success") }，避免把拦截日志当成成功请求 - 跨域中间件若在
c.Abort()后仍写Access-Control-Allow-Origin，浏览器会忽略（但浪费字节）
真正决定链路走向的是 c.index 的值和你是否调 c.Next()，c.IsAborted() 只是读取这个状态的快捷方式 —— 它不干预流程，只帮你做判断。
