中间件剥离是将日志、鉴权等非业务逻辑从handler中抽离为可复用、可插拔的独立函数，本质是http.Handler嵌套包装，在调用原handler前后插入逻辑；Gin中通过c.Next()实现洋葱模型，解耦关键在于依赖接口而非具体实现。
中间件剥离不是删掉中间件，而是把原本混在 handler 里的非业务逻辑（比如日志、鉴权、耗时统计）抽出来，变成可复用、可插拔的独立函数。它直接解决「每个 handler 都要复制粘贴同一段代码」的问题。
Go 标准库中 middleware 的本质是 http.Handler 嵌套
标准库没有叫「middleware」的类型，只有 http.Handler 和 http.HandlerFunc。中间件就是一种包装：接收一个 http.Handler，返回另一个 http.Handler，在调用原 handler 前后插入逻辑。
常见错误现象：
- 直接在 handler 里写
log.Println()+next.ServeHTTP()—— 这不是中间件，是硬编码 - 忘记调用
next.ServeHTTP()，导致请求卡住，无响应 - 把中间件写成普通函数但没返回
http.Handler，无法被http.ListenAndServe()接收
正确写法示例（耗时统计中间件）：
func TimingMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
start := time.Now()
next.ServeHTTP(w, r)
log.Printf("%s %s %v", r.Method, r.URL.Path, time.Since(start))
})
}
使用方式：http.ListenAndServe(":8080", TimingMiddleware(mux))
Gin 框架里用 c.Next() 实现洋葱模型
Gin 的中间件更直观，靠 *gin.Context 和 c.Next() 控制执行流。前置逻辑写在 c.Next() 前，后置逻辑写在后面，天然支持「进入→业务→退出」三段式。
容易踩的坑：
- 在中间件里调用
c.Abort()后还继续执行后续逻辑 ——c.Abort()只是中断链，不会自动 return，必须手动加return - 用
c.Set("key", val)存数据，但在下一个中间件或 handler 里忘了用c.Get("key")取，或者类型断言失败 - 多个中间件注册顺序错乱，比如鉴权中间件放在日志之后，导致未授权请求也被记日志
典型结构：
func AuthMiddleware() gin.HandlerFunc {
return func(c *gin.Context) {
token := c.GetHeader("Authorization")
if !isValidToken(token) {
c.AbortWithStatusJSON(401, gin.H{"error": "unauthorized"})
return // 必须加
}
c.Next() // 放行
}
}
解耦的关键不是用中间件，而是把依赖抽象成接口
中间件只解决「横切逻辑复用」，真正让业务代码解耦的是依赖倒置：让 handler 不依赖具体实现（比如 *sql.DB 或 *redis.Client），而是依赖接口（如 UserRepository）。
为什么这么做：
- 测试时可注入 mock 实现，不用连真实数据库
- 切换底层存储（MySQL → PostgreSQL → 内存缓存）只需改初始化，不碰 handler
- 中间件和业务 handler 都能通过同一接口访问数据，职责彻底分离
示例接口定义：
type UserRepository interface {
GetByID(ctx context.Context, id int) (*User, error)
Save(ctx context.Context, u *User) error
}
handler 中只持有该接口，不关心谁实现它；中间件也只操作 *gin.Context 或 http.ResponseWriter，不碰业务数据层。
最常被忽略的一点：中间件之间传递数据靠 c.Set() / c.Get() 或 context.WithValue()，但值的 key 必须是全局唯一变量（不能是字符串字面量），否则跨包取值会失败或 panic。解耦越深，越要提前约定好 key 类型和生命周期。
