Gin中间件执行顺序完全由router.Use()调用顺序及路由注册位置决定，本质是函数嵌套的洋葱模型；c.Next()为控制权交接点，Abort()后必须return，否则业务逻辑仍会执行。
中间件执行顺序由注册位置决定，不是靠“全局配置”
Gin 没有中间件执行优先级数字、权重或配置项来控制先后。顺序完全取决于你调用 router.Use() 或 group.Use() 的时机，以及路由注册的位置。
常见错误是以为“先注册的中间件就先执行”，其实关键在：谁包着谁。Gin 的中间件链本质是函数嵌套，Use() 会把后续所有注册的路由 handler 包进当前中间件里；而 GET() 等路由方法注册的是最内层 handler。
-
router.Use(m1, m2)→router.GET("/a", h)：执行顺序是m1 → m2 → h -
router.Use(m1)→router.GET("/a", h)→router.Use(m2)→router.GET("/b", h)：/a 走m1 → h，/b 走m1 → m2 → h - 分组时：
v1 := router.Group("/api/v1")→v1.Use(auth)→v1.GET("/user", handler)：auth 只作用于 /api/v1 下的路由，不干扰 /health 等顶层路由
洋葱模型不是比喻，是真实调用栈展开
c.Next() 不是“继续往下走”，而是显式触发下一层 handler 的执行。它像一个控制权交接点：当前中间件执行到 c.Next() 之前的部分（前置逻辑），然后跳进下一层，等那层完全返回后，再继续执行 c.Next() 之后的代码（后置逻辑）。
这意味着：日志中间件想记录完整耗时，必须在 c.Next() 前打开始时间，之后取结束时间；而认证中间件若在 c.Next() 前 abort，后面所有层（包括日志的后置部分）都不会执行。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 错误写法：
if !valid { c.Abort(); return }放在c.Next()后面 → 已经进过业务逻辑了 - 正确结构：
func logging() gin.HandlerFunc { return func(c *gin.Context) { start := time.Now() c.Next() // ← 这里才真正进入 auth → service 链 log.Printf("%s %s %v", c.Request.Method, c.Request.URL.Path, time.Since(start)) } }
Abort() 必须配 return，否则请求不会真正中断
c.Abort() 只是标记当前上下文已中止，不会自动跳出函数。如果后面还有 c.JSON() 或 c.String()，它仍会执行——但此时 HTTP 头可能已被前面中间件写过，导致 http: multiple response.WriteHeader calls panic。
更危险的是漏掉 return：比如权限校验失败后只写 c.Abort() 却没 return，后续代码（如数据库查询、发消息）照常运行，业务逻辑被绕过但副作用已发生。
- 必须成对出现：
c.Abort(); c.JSON(401, ...); return - 别依赖 defer 清理：defer 在函数 return 后才执行，abort 后若没 return，defer 依然会跑，但此时 context 已失效
- Gin 内置的
Recovery()中间件就是靠 recover +c.Abort()+return拦住 panic 后的流程
真实 IP 解析失败常因 SetTrustedProxies 配置缺失
线上环境 c.ClientIP() 返回 127.0.0.1 或内网地址，不是函数 bug，而是 Gin 默认只信任本地回环网段。它需要你明确告诉框架哪些代理 IP 是可信的，才能安全地从 X-Forwarded-For 提取最左非信任地址。
不设 SetTrustedProxies 就直接解析 X-Forwarded-For，等于把攻击者可伪造的请求头当真——比如客户端传 X-Forwarded-For: 1.2.3.4, 5.6.7.8，你取最右就中招；取最左又可能拿到 CDN 公网 IP 而非用户真实出口 IP。
- 正确做法：
router.SetTrustedProxies([]string{"192.168.0.0/16", "10.0.0.0/8", "203.208.60.0/24"})（填你实际的 Nginx/CDN 网段） - 若 Nginx 已配
proxy_set_header X-Real-IP $remote_addr，优先读c.Request.Header.Get("X-Real-IP")，更简单可靠 - 切勿写
SetTrustedProxies(nil)或空 slice，这会让 Gin 回退到只信 localhost，线上必然失效
中间件链越深，c.Next() 和 c.Abort() 的耦合越紧。一个中间件里少写一行 return，就可能让整个拦截逻辑形同虚设——这不是语法问题，是控制流设计本身的要求。
