中间件执行顺序遵循洋葱模型，由Use()调用顺序决定：请求依次进入mwA→mwB→mwC前半段，执行handler后，再逐层返回执行各中间件后半段；c.Next()是流转核心，挂起当前中间件让后续中间件和handler执行完毕后再继续；c.Abort()终止后续所有处理，需手动响应；数据共享须用c.Set()/c.Get()，避免全局变量或修改c.Request。
中间件执行顺序由Use()调用顺序决定
注册中间件时，Use() 的调用顺序直接决定请求进入时的执行顺序。比如 r.Use(mwA, mwB, mwC)，请求会先执行 mwA 前半段 → mwB 前半段 → mwC 前半段 → handler → mwC 后半段 → mwB 后半段 → mwA 后半段。这不是线性队列，而是“洋葱模型”：进一层、再进一层、到底层、再逐层返回。
常见错误是误以为后注册的中间件会“覆盖”前面的——实际它只是被压到栈顶，最先被进入、最后被退出。调试时可加日志观察 c.Next() 前后的打印时机，确认是否符合预期嵌套。
c.Next() 是流转控制的核心开关
c.Next() 不是“跳到下一个中间件”，而是把当前中间件的执行权暂时挂起，让后续所有中间件和最终 handler 先跑完，再回来继续执行 c.Next() 之后的代码。它必须出现在中间件函数体中，且只能调用一次——重复调用会导致 handler 执行两次，可能引发 panic 或数据重复写入。
- 没调用
c.Next()：后续中间件和 handler 完全不执行，请求在此中断（除非你主动c.JSON()等响应） - 调用位置靠后：前置逻辑做完后才放行，适合鉴权或参数校验类中间件
- 放在开头：相当于“并行预处理”，但要注意此时 handler 还没执行，无法获取响应状态码等信息
c.Abort() 终止流转，跳过所有后续环节
一旦调用 c.Abort()，当前中间件及之后所有中间件、handler 都不会再执行。注意：c.Abort() 不会自动返回响应，你得自己写 c.JSON(401, ...) 或 c.String(403, ...)，否则客户端会卡住等待超时。
立即学习“go语言免费学习笔记（深入）”；
典型场景包括：
- Token 解析失败，立即
c.AbortWithStatusJSON(401, gin.H{"msg": "unauthorized"}) - IP 黑名单拦截，调用
c.Abort()后直接c.String(403, "forbidden") - 路由组级权限检查未通过，避免浪费资源进入子路由
别在 c.Next() 之后调用 c.Abort() —— 此时 handler 已执行，响应可能已写出，再 abort 没有意义，还可能触发 “http: response.WriteHeader on hijacked connection” 错误。
中间件间共享数据要用 c.Set()/c.Get()
请求生命周期内，多个中间件需要协作时（比如解析 Body 后供下游使用），不能靠全局变量或闭包捕获，必须用 c.Set("key", value) 和 c.Get("key")。Gin 的 *gin.Context 是 per-request 实例，天然线程安全。
容易踩的坑：
- 类型断言要带 ok 判断：
if val, ok := c.Get("parsed_body"); ok { ... } - 不要往
c.Request上塞字段——c.Request是 net/http 标准结构，扩展字段会被忽略 - 避免在中间件里反复解析 Body；推荐只在一个中间件里
c.ShouldBindJSON()并c.Set()，其他中间件直接c.Get()
真正复杂的流转控制（比如条件跳过某中间件、动态插入中间件链）在 Gin 中并不原生支持——它依赖静态注册 + c.Abort() / c.Next() 组合实现，过度动态化反而破坏可读性和调试性。
