c.Abort()是唯一可靠方式，因它设置c.isAborted=true，使Gin跳过链中所有剩余中间件和最终处理器；仅return或省略c.Next()均无法阻止后续执行。
直接中断 Gin 中间件链，靠 c.Abort()，不是 return，也不是跳过 c.Next() —— 后两者单独用都不够。
为什么 c.Abort() 是唯一可靠方式
Gin 的中间件链是状态驱动的：它内部维护一个 c.isAborted 标志位。只有调用 c.Abort() 才会把这个标志设为 true，后续所有中间件和最终处理器（比如路由绑定的 func(c *gin.Context)）才会被跳过。
常见误区：
- 只写
return：当前函数退出，但 Gin 仍会继续执行链上剩余中间件和 handler - 不调用
c.Next()：仅对「当前中间件之后的逻辑」无影响；如果这是最后一个中间件，业务 handler 依然会被执行 - 只调用
c.JSON()+return：响应发出去了，但 handler 还是照常跑，可能重复写响应、panic 或查库
c.Abort() 必须在 c.JSON() 等响应方法之后立即调用
顺序错了会导致 HTTP 状态码或 body 错乱，甚至 panic（如多次写 header）。
正确写法：
if token == "" {
c.AbortWithStatusJSON(401, gin.H{"error": "missing token"})
return
}
等价于：
if token == "" {
c.JSON(401, gin.H{"error": "missing token"})
c.Abort()
return
}
错误写法（c.Abort() 放前面）：
if token == "" {
c.Abort() // 此时还没写响应，c.JSON() 会 panic
c.JSON(401, gin.H{"error": "missing token"})
return
}
短路后不能再调用 c.Next() 或访问 c.Writer
一旦 c.Abort() 被调用，Gin 就认为该请求生命周期已终结。此时再操作 c.Writer（比如 c.String()、c.Data()）会触发 panic，日志里通常报 http: response.WriteHeader on hijacked connection 或类似错误。
典型踩坑场景：
- 在
defer里统一写日志或记录耗时，但没判断c.IsAborted() - 多个中间件都做鉴权，第二个中间件没检查是否已被前一个
Abort()，还试图读取c.Get("user")导致 nil panic - 自定义 recovery 中间件放在链末尾，却想捕获前面已
Abort()的 panic —— 实际不会触发，因为链早就断了
全局 vs 路由级中断行为一致，但注册位置决定作用范围
c.Abort() 的效果跟中间件注册方式无关，只取决于它是否被执行。但注册位置决定了“谁有机会执行它”：
- 用
router.Use(AuthMiddleware)：所有路由都受控，未登录请求根本进不到业务 handler - 用
group.Use(AuthMiddleware)：仅该 group 下的路由被保护，/public 路由不受影响 - 单个路由传入：
router.POST("/pay", AuthMiddleware, payHandler)：只有这个接口受保护
注意：如果在全局中间件里 Abort()，后续所有中间件和 handler 都不会执行；但如果某个路由没注册该中间件，Abort() 就压根不会被调用 —— 它不带“拦截规则”，只响应“当前链上是否运行到它”。
