gin中间件是func(*gin.context)类型函数链，靠c.next()推进流程、c.abort()终止后续中间件和handler执行；c.abort()后调用c.next()会出错，因c.abort()仅阻止未执行的后续链，但不终止当前函数，若未return，c.next()仍会触发重复响应或panic。
直接说结论：Gin 的中间件不是“拦截器”概念，而是 gin.HandlerFunc 类型的函数链，用 c.Next() 控制流程走向，用 c.Abort() 或提前 c.JSON() 终止后续处理——它不拦截 HTTP 连接，只拦截请求进入 handler 前后的执行权。
为什么 c.Abort() 后还调用 c.Next() 会出错？
这是最常踩的坑。Gin 中间件执行顺序是线性的，c.Next() 表示“把控制权交给下一个中间件或最终 handler”，但它不会自动跳过后续代码。如果你在返回错误后忘了 return，后续逻辑仍会执行：
- 错误写法：
c.JSON(401, gin.H{"error": "unauthorized"}); c.Next();→ 会继续执行后续中间件甚至 handler，可能触发http: multiple response.WriteHeader calls - 正确写法：
c.JSON(401, gin.H{"error": "unauthorized"}); c.Abort(); return;→c.Abort()阻止后续中间件执行，return防止本函数继续往下跑 -
c.Abort()只影响当前中间件链中“尚未执行”的后续中间件，不影响已执行过的（比如日志中间件已经打完日志了）
gin.Default() 自带的中间件有哪些？能不能关掉？
gin.Default() 等价于 gin.New().Use(gin.Logger(), gin.Recovery())，默认启用两个中间件：
-
gin.Logger()：打印请求方法、路径、状态码、耗时；输出到标准输出，不可配置格式 -
gin.Recovery()：用recover()捕获 panic，返回 500 并记录堆栈；但默认不透出具体错误信息给客户端（避免泄露服务细节） - 如需关闭日志：
r := gin.New()，然后手动r.Use()添加需要的中间件 - 如需自定义 Recovery（比如带上 trace ID 或结构化错误）：自己写一个中间件替代
gin.Recovery()，注意 defer + recover +c.Abort()三者必须配对
如何让多个中间件共享数据（比如用户 ID、请求 ID）？
Gin 的 *gin.Context 是贯穿整个请求生命周期的数据载体，推荐用 c.Set() / c.MustGet() 传递值：
- 设置：
c.Set("user_id", 123)，支持任意类型（包括 struct、map） - 读取：
uid := c.MustGet("user_id").(int)，注意类型断言；若不确定是否存在，用c.Get()返回interface{}和bool - 不要用全局变量或闭包捕获的变量存请求级数据——并发下不安全，且无法隔离不同请求
- 常见组合：鉴权中间件写
c.Set("user", user)，后续业务 handler 直接读，避免重复查 DB
自定义中间件怎么传参？比如不同路由用不同密钥校验 API Key
Go 没有“注册即生效”的中间件机制，必须靠闭包捕获参数。典型模式是返回函数的函数：
func APIKeyMiddleware(expected string) gin.HandlerFunc {
return func(c *gin.Context) {
key := c.Request.Header.Get("X-API-Key")
if key != expected {
c.JSON(403, gin.H{"error": "forbidden"})
c.Abort()
return
}
c.Next()
}
}
使用时：r.Use(APIKeyMiddleware("prod-secret")) 或 r.GET("/admin", APIKeyMiddleware("admin-key"), handler)。注意：
- 闭包捕获的是值拷贝，
expected string安全；若传*sync.Map等需自行加锁 - 别把中间件定义成
func(c *gin.Context)然后试图“动态改 expected”——那会破坏闭包语义，导致所有实例共用最后一个值 - 复杂配置建议用结构体封装，比如
type AuthConfig struct { Secret string; Timeout time.Duration }，再提供func(c *AuthConfig) gin.HandlerFunc
真正难的不是写中间件，而是想清楚哪些逻辑该放进去、哪些该留在 handler 里——比如权限检查放中间件，但字段级校验（如邮箱格式）更适合放在 handler 内部，否则中间件会越来越重、难以复用。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
