中间件执行依赖c.next()位置与调用逻辑：注册顺序决定执行顺序，c.next()前为请求阶段、后为响应阶段，未调用则后续不执行；context共享但非线程安全，数据传递用set/get，writer状态读取须在c.next()后。
中间件不是“插进去就自动跑”，它的执行时机、顺序和中断行为，完全取决于 c.Next() 的位置和调用逻辑——不理解这点，写出来的中间件要么不生效，要么 panic，要么漏掉后置逻辑。
中间件的执行顺序由注册位置决定
Gin 的中间件链是静态构建的：在 r.Use() 或 group.Use() 时，函数指针被追加到 HandlersChain 切片里，后续请求按索引顺序依次调用。没有运行时动态插入或跳过机制。
- 全局中间件（
r.Use(m1, m2)）会出现在所有路由的处理链最前面 - 路由组中间件（
api.Use(m3)）只影响该组下的路由，且排在全局中间件之后、具体 Handler 之前 - 同一个组内多次
Use()，顺序就是代码书写顺序，不是声明顺序 - 如果中间件里没写
c.Next()，后续所有中间件 + 最终 Handler 都不会执行
c.Next() 是生命周期分水岭
中间件函数体中，c.Next() 前的代码是“请求进入阶段”，c.Next() 后的代码是“响应返回阶段”。Gin 用栈式调用模拟洋葱模型，c.Next() 触发下一层，返回后继续执行当前层的后半段。
- 错误场景：
c.Abort()或c.AbortWithStatusJSON()会清空剩余链，直接跳出整个调用栈 - 常见误用：在
c.Next()后仍尝试读取请求体（如c.ShouldBindJSON()），此时 body 已被前序中间件或 Handler 消费，会返回io.EOF - 日志类中间件必须把耗时计算放在
c.Next()后，否则测的是“到它为止”的时间，不是整条链耗时
Context 生命周期与中间件数据传递
*gin.Context 是单次请求的唯一上下文实例，从引擎入口一直透传到底层 Handler，所有中间件共享同一份引用。但它的字段（如 Keys、Errors、Request、Writer）不是线程安全的，也不支持并发修改。
- 存数据用
c.Set("key", value)，取用c.Get("key")，这是最轻量的跨中间件通信方式 - 不要在中间件里修改
c.Request的Body字段——它是一次性流，改了会影响后续绑定；如需复用，得提前用c.Request.Body = ioutil.NopCloser(bytes.NewReader(buf))替换 -
c.Copy()返回新 Context 实例，但仅用于 goroutine 安全场景，日常鉴权/日志无需 copy - 一旦调用了
c.Writer.WriteHeader()或c.JSON()等写响应方法，就不能再调用c.Abort()来拦截，HTTP header 已发送，客户端可能已开始接收 body
真正容易被忽略的，是 c.Next() 调用前后对 c.Writer 状态的依赖关系——比如压缩中间件必须在 c.Next() 前设置 gzip.Writer，而日志中间件必须在 c.Next() 后读取 c.Writer.Status() 和 c.Writer.Size()，顺序反了就拿不到真实状态。
