gin中间件核心是c.next()控制权移交和洋葱模型双向执行流；漏掉或错放c.next()会导致请求卡死，不调用则后续handler不执行，位置错误如c.abort()后调用无效，前置校验失败需c.abort()防越权。
Gin中间件不是“加个函数就完事”，核心在于理解 c.Next() 的控制权移交逻辑和洋葱模型的双向执行流；漏掉 c.Next() 或放错位置，请求就会静默卡死，连 404 都不返回。
为什么中间件不执行后续 handler？
最常见错误：写了中间件函数，但没调用 c.Next()。Gin 不会自动推进流程，必须显式调用它才能进入下一个中间件或路由处理器。
- 不调用
c.Next()→ 请求在当前中间件阻塞，后续所有中间件和 handler 完全不执行 - 调用位置错误（比如写在
c.Abort()后）→ 实际不会生效，因为c.Abort()已终止链 - 前置校验失败后忘记
c.Abort()→ 即使校验失败，请求仍会继续往下走，造成越权访问
如何正确分离前置与后置逻辑？
洋葱模型决定了代码执行顺序：所有中间件的“前半段”按注册顺序依次执行，到 handler 后再“回弹”执行各中间件的“后半段”。c.Next() 就是前后分界点。
-
c.Next()前：适合读取 Header、校验 Token、设置上下文（如c.Set("userID", id)） -
c.Next()后：能拿到最终状态码（c.Writer.Status()）、响应耗时、甚至响应体大小（c.Writer.Size()），适合日志、监控、响应体改写 - 注意：
c.Writer.StatusWritten才表示响应头已发送，此时不能再改状态码或 Header
全局中间件 vs 路由组中间件执行顺序怎么算？
注册顺序 ≠ 执行顺序。全局中间件（engine.Use()）包裹整个路由树，而路由组中间件（group.Use()）插在全局中间件“内层”，更靠近 handler。
- 示例：
engine.Use(m1)→api := engine.Group("/api")→api.Use(m2)→api.GET("/user", h) - 真实执行流：
m1前 →m2前 →h→m2后 →m1后 - 404 请求会触发
m1，但不会触发m2（因为没匹配到/api组） - 别把健康检查（如
/healthz）和耗时操作（如 DB 查询）塞进全局中间件，否则所有请求都受影响
如何安全地终止中间件链并返回响应？
直接 c.JSON() + c.Abort() 是危险组合：如果 handler panic，c.JSON() 可能没真正写出，而 c.Abort() 又阻止了 Recovery 中间件捕获 panic。
- 优先用
c.AbortWithStatusJSON(401, gin.H{"error": "xxx"})—— 原子操作，既设响应又终止链 - 需要自定义错误格式？用
c.AbortWithStatus()+c.Render()，确保 writer 正确 flush -
c.Abort()后不要再访问c.Writer，否则可能 panic（writer 已被标记为 aborted）
真正容易被忽略的是：中间件后置逻辑里看到的 c.Writer.Status() 是最终状态码，但 c.Writer.Body() 并不等于实际发出去的响应体——Gin 默认使用 responseWriter 包装，内容可能被压缩、重写或缓冲未 flush。要修改响应体，得用 c.Writer.Write() 并手动处理 Content-Length 和 Content-Encoding 头。
