c.next()是中间件链显式调度的唯一方式，必须在前置逻辑后、后置逻辑前调用；漏写、错放或条件分支中遗漏会导致链中断；配合c.abort()和return才能正确终止流程。
c.Next() 是中间件链执行的唯一调度点
中间件不是自动串起来的，Gin 不会帮你“隐式调用下一个”。c.Next() 是显式跳转到后续中间件或路由处理函数的唯一方式。漏写、错放位置、或在条件分支里漏调用，都会导致链中断——后面所有中间件和业务逻辑都不执行。
常见错误现象：Logger 打印了请求开始但没打印完成；Recovery 捕获不到 panic；自定义认证中间件返回 401 后业务 handler 仍被执行。
-
c.Next()必须出现在中间件函数体中，且通常放在前置逻辑之后、后置逻辑之前 - 如果前置逻辑判断失败（如 token 无效），应调用
c.Abort()并立即返回，避免执行c.Next() - 多个
c.Next()调用不会报错，但会导致重复执行后续链，引发状态混乱（比如日志打两遍、DB 事务重复提交）
中间件注册顺序 = 执行顺序（洋葱模型）
注册时用 r.Use(m1, m2, m3)，实际执行是“进层”时按序触发前置逻辑，“出层”时逆序触发后置逻辑。这决定了数据注入、上下文修改、错误拦截的生效范围。
使用场景：你想让日志看到最终状态码，就得把 Logger 放在 Recovery 之后；想让 JWT 解析结果被后续所有中间件读取，就得把 TokenRequired 放在依赖它的权限中间件之前。
- 全局
r.Use()注册的中间件对所有路由生效，但顺序靠前的中间件无法读取靠后中间件通过c.Set()写入的数据 - 路由组级中间件（如
adminGroup.Use(auth)）只影响该组内路由，且叠加在全局中间件之后 - 单个路由上追加的中间件（如
r.GET("/x", m1, handler)）会在该路由执行时插入到链末尾
中间件共享数据靠 *gin.Context.Set() 和 .Get()
*gin.Context 是整个请求生命周期内唯一的上下文载体，中间件之间不能靠闭包变量传值，必须用 c.Set(key, value) 显式存、c.Get(key) 显式取。
容易踩的坑：在中间件里直接声明局部变量赋值，以为后续中间件能访问；或者用 c.GetString() 等类型断言方法前没检查 ok 返回值，导致 panic。
-
c.Set()存的是 interface{}，取值务必用c.Get()+ 类型断言，或更安全的c.MustGet()（当确定 key 一定存在时） - key 建议用常量定义，避免字符串拼写错误，例如
const UserKey = "user" -
c.Copy()仅用于并发 goroutine 场景（如异步日志），普通中间件链中无需调用
Abort() 和 return 的区别很关键
c.Abort() 是 Gin 提供的“软终止”机制：它只是把 c.index 设为最大值，阻止后续中间件执行，但当前中间件函数体仍会继续往下跑。而 return 是 Go 层面的函数退出，两者必须配合使用。
典型误用：只调 c.Abort() 没 return，导致后续代码（比如 c.Next() 或响应写入）仍被执行。
- 正确写法：
c.Abort(); c.JSON(401, gin.H{"msg": "unauthorized"}); return -
c.AbortWithStatusJSON()是封装好的快捷方式，内部已含Abort()和return，可直接用 - 一旦调过
c.Abort()，再调c.Next()无效，但不会 panic
return，或者 c.Set() 和 c.Get() 的 key 对不上——这种问题不会报错，只会静默失效。
