gin.handlerfunc是自定义中间件的唯一入口，必须是接收*gin.context、返回空的函数，需显式调用c.next()或c.abort()；c.next()同步阻塞执行后续中间件和handler，c.abort()终止链路但允许写响应；多次读body需提前缓存；闭包用于传参配置；顺序错位会导致鉴权失效或日志遗漏；goroutine中必须用c.copy()避免上下文被回收。
gin.HandlerFunc 就是自定义中间件的唯一入口，不是“可以这么写”，而是“必须这么写”——它本质就是一个接收 *gin.Context 的函数，且必须显式调用 c.Next() 或 c.Abort() 控制流程。
怎么写一个能用的中间件函数
最简形式就是定义一个参数为 *gin.Context、返回值为空的函数，内部通过 c.Next() 放行后续处理，或 c.Abort() 终止链路：
-
c.Next()不是“自动往下走”，而是**同步阻塞执行后续中间件和 handler**，等它们全部返回后才继续执行c.Next()后面的代码（常用于日志耗时统计） -
c.Abort()会跳过所有后续中间件和最终 handler，但不会中断当前中间件函数体——所以c.Abort()后仍可写响应逻辑，比如c.JSON(401, ...) - 别在中间件里直接用
c.Request.Body多次读取——它是一次性流，第二次读就是空；如需多次访问，得提前ioutil.ReadAll并用c.Request.Body = io.NopCloser(...)替换
为什么闭包方式比普通函数更常用
因为真实项目里几乎从不写“裸中间件”，总要传配置，比如日志级别、白名单路径、密钥前缀。这时就得用闭包返回 gin.HandlerFunc：
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 错误写法：
func AuthMiddleware(role string) { ... }—— 返回值不是gin.HandlerFunc，Gin 拒绝注册 - 正确写法：
func AuthMiddleware(requiredRole string) gin.HandlerFunc { return func(c *gin.Context) { ... } } - 典型场景：给不同路由组配不同权限策略，
admin := r.Group("/admin").Use(AuthMiddleware("admin"))，user := r.Group("/user").Use(AuthMiddleware("user"))
中间件顺序错位会导致什么问题
Gin 中间件是链式调用，顺序即执行顺序，错一位就可能让鉴权失效或日志漏记：
- 日志中间件必须在最外层（
r.Use(Logging())），否则c.Next()耗时统计不准，panic 也可能没被记录 - 鉴权中间件必须在业务 handler 前、且在 Recovery 之后——如果 Recovery 包裹了 Auth，panic 发生在 Auth 内部就捕获不到；但如果 Auth 在 Recovery 外，panic 会直接崩掉服务
- 不要把
Recovery放到某个Group().Use()里——它只对那个分组生效，全局 panic 仍会 crash
为什么 c.Copy() 在 goroutine 里必不可少
中间件中起 goroutine 处理异步任务（如审计日志上报、消息推送）时，*gin.Context 不能直接传入协程——因为主线程返回后，原上下文会被回收，字段变零值甚至 panic：
- 必须用
cCp := c.Copy()创建副本，再传进go func() { ... }() -
c.Copy()只拷贝 context 数据结构，不拷贝底层 request/response body，所以仍要注意 Body 读取问题 - 别依赖
c.Get("key")在 goroutine 里取值——如果 key 是上一个中间件c.Set()的，而那个中间件在c.Next()后才执行，那副本里就没有这个 key
c.Set("user", u) 没问题；但数据库连接池管理，就不该塞进中间件——那是初始化阶段的事。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
