c.next() 是“跳转并回调”而非“继续执行”，调用后立即跳转至下一 handler，待其执行完毕再返回当前中间件 c.next() 后续代码，形成洋葱模型的回程路径。
c.Next() 不是“继续执行”，而是“跳转并回调”
很多人误以为 c.Next() 是让当前中间件“接着往下走”，其实它更像一个控制权移交点：调用后立即跳转到链中下一个 handler（可能是另一个中间件，也可能是最终的路由处理函数），等那个 handler 完全执行完（包括它自己的 c.Next() 和后续代码），再回到当前中间件里 c.Next() 后面的语句继续执行。
这导致实际输出顺序和代码书写顺序相反——前置逻辑在 c.Next() 前，后置逻辑在 c.Next() 后，但后者总在业务 handler 执行完才运行。
- 如果中间件 A 中没写
c.Next()，A 执行完就结束，后续中间件和路由 handler 都不会触发 - 如果中间件 B 在
c.Next()后还写了c.Abort()，那它后面的代码仍会执行，但后续 handler 不会执行 -
c.Next()只能被调用一次；重复调用不会报错，但第二次起无效（因为c.index已越界）
多个中间件共用 c.Next() 时的执行顺序
注册顺序决定洋葱入层顺序，而 c.Next() 决定回程路径。比如注册了 M1、M2、Handler，实际执行流是：
M1 → M2 → Handler → M2（c.Next() 后）→ M1（c.Next() 后）
- 所有中间件必须显式调用
c.Next()才能进入下一层；漏掉一个，整条链就断在那一层 - 全局中间件（
r.Use()）和路由级中间件（r.GET("/x", m1, m2, h)）会合并成一个 handlers 切片，按注册+声明顺序拼接 - 路由分组（
api := r.Group("/api")）里的Use()会追加到该 group 的 handlers 开头，优先于 group 内单个路由声明的中间件
c.Next() 和 c.Abort() 混用的常见陷阱
c.Abort() 不会阻止当前中间件内 c.Next() 后面的代码执行，只跳过后续 handler。这是最容易踩坑的地方。
- 错误写法：
c.Abort(); c.Next()——c.Next()被忽略，但c.Abort()后面的其他语句照常运行 - 正确拦截模式：验证失败时应
c.Abort()并立即返回响应，避免后续逻辑干扰（比如日志中间件还在记耗时，但 handler 根本没跑） - 如果某个中间件既要做前置校验又要记录后置指标，必须把指标统计逻辑放在
c.Next()之前判断是否已c.IsAborted()
为什么有时 c.Next() 像没生效？
典型表现：中间件里写了 c.Next()，但业务 handler 就是不执行。常见原因有：
- 中间件被注册到了错误位置，比如放在了
router.GET(..., handler)的 handler 参数之后（Gin 只把handler前面的函数当中间件） - 路由未匹配成功，根本没走到该 handler 链（检查
curl -v返回的 404 或 405） - 上游中间件调用了
c.Abort()且没写响应体，导致连接挂起或客户端超时 - 中间件 panic 且没被 recover，整个链中断（Gin 默认 recover 中间件只捕获顶层 panic）
真正难调试的，往往是 c.Next() 看似执行了，但业务逻辑因上下文状态被意外修改而行为异常——比如鉴权中间件往 c 里塞了错误的 user 对象，后面 handler 读取时出错，这种问题不会报错，只会逻辑错乱。
