自定义路由组中间件拿不到注入依赖，因gin中间件只接受无参函数值，无法自动携带结构体字段；正确做法是用闭包工厂函数（如newauthmiddleware(db,cfg)）提前绑定依赖并返回gin.handlerfunc。
为什么自定义路由组中间件里拿不到注入的依赖
因为中间件函数本身是无状态的闭包，它不自动携带任何结构体字段或外部变量；你写的 func(c *gin.Context) 里没有 DB、Config 或 Service 实例，除非显式传入或从上下文取——而从 c.Keys 取是反模式，类型丢失且易出错。
常见错误现象：
- 在中间件里调用
db.QueryRow()报nil pointer dereference -
c.Get("DB")返回nil或断言失败：db := c.MustGet("DB").(*sql.DB)panic - 测试时 mock 不了依赖，中间件逻辑无法单独验证
根本原因：Gin 的中间件注册机制只接受函数值，不支持带参数的构造器。所以不能像 Controller 那样把 *models.DB 当字段塞进去。
如何让路由组中间件拿到真实依赖（非 context.Keys）
唯一安全的方式是把依赖提前绑定到中间件函数上，生成一个“闭包中间件”。这不是 Gin 特性，而是 Go 语言闭包的自然用法。
实操建议：
- 定义中间件工厂函数，接收依赖作为参数，返回
gin.HandlerFunc - 在
r.Group()前调用该工厂，生成带依赖的中间件实例 - 避免在 handler 或中间件内部做
c.Set()注入，那只是临时打补丁
示例：
func NewAuthMiddleware(db *models.DB, cfg *config.Config) gin.HandlerFunc {
return func(c *gin.Context) {
token := c.Request.Header.Get("Authorization")
user, err := db.ValidateToken(token)
if err != nil {
c.AbortWithStatusJSON(401, gin.H{"error": "invalid token"})
return
}
// 用 Set 存用户信息（元数据），不是存 db！
c.Set("user", user)
c.Next()
}
}
注册时：
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
admin := r.Group("/admin")
admin.Use(NewAuthMiddleware(db, cfg)) // ✅ 依赖已绑定
admin.GET("/users", handler)
路由组中间件与全局中间件的依赖作用域差异
全局中间件（r.Use()）和路由组中间件（group.Use()）共享同一个 *gin.Engine，但它们的执行时机和作用域不同——这直接影响依赖的可见性。
关键点：
- 全局中间件在所有路由前执行，但若你在其中
c.Set("DB", db)，后续中间件仍需手动c.MustGet("DB")，且类型要自己断言 - 路由组中间件只对本组生效，适合按业务隔离依赖（如 admin 组用 adminDB，api 组用 readOnlyDB）
- 不要指望全局中间件“预设好”所有依赖再让子 group 拿——那是混淆了数据传递（context）和依赖注入（构造期）
性能影响：闭包捕获依赖无额外开销，Go 编译器会优化为函数指针+隐式参数；比反复断言 c.Keys 更快也更安全。
排查时最容易忽略的三个点
一是中间件工厂函数没被调用，比如写了 NewAuthMiddleware(db, cfg) 却忘了加括号执行，结果传的是函数地址而非函数值；
二是依赖本身是 nil，比如 db 初始化失败但没检查错误，闭包里直接 panic；
三是多层 Group 嵌套时，误以为父 group 的中间件能自动把依赖透传给子 group —— Gin 没有这种穿透机制，每个 Group() 是独立作用域，必须显式传。
