Gin中间件本质是gin.HandlerFunc类型函数，构成HandlersChain切片链表，通过c.Next()推进执行、c.Abort()中断流程，遵循洋葱模型：A前→B前→C前→路由→C后→B后→A后。
中间件本质就是 HandlerFunc 链
Gin 中间件没有魔法，它就是 gin.HandlerFunc 类型的函数，和路由处理函数类型完全一致。区别只在于调用方式：中间件必须显式调用 c.Next() 才能把控制权交给下一个处理器，否则请求就卡住不动了。
所有注册的中间件（包括路由处理函数）最终都存进 HandlersChain 这个切片里，按注册顺序排队执行。你可以把它理解成一个函数数组：[]gin.HandlerFunc，Gin 在匹配到路由后，就从头开始依次调用。
-
c.Next()不是“跳到下一个中间件”，而是触发当前链中剩余函数的执行；它内部靠一个索引游标推进 - 调用
c.Abort()会直接清空后续未执行的 handler，但已进入的中间件后置逻辑仍会执行（比如日志记录里的耗时统计） - 中间件可以嵌套调用——
c.Copy()常用于异步场景，但要注意它不共享c.Keys和写入响应的能力
洋葱模型不是比喻，是执行栈结构
所谓“洋葱模型”，指中间件执行呈现 前半段 → 路由处理 → 后半段 的嵌套结构。这不是设计选择，而是 c.Next() 递归调用导致的自然结果：
比如注册了 A、B、C 三个中间件，实际执行顺序是：A前 → B前 → C前 → 路由函数 → C后 → B后 → A后。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 前置逻辑在
c.Next()之前，适合鉴权、参数预处理、上下文初始化 - 后置逻辑在
c.Next()之后，适合日志记录、响应包装、资源清理 - panic 发生时，Recovery 中间件能捕获，是因为它在链最外层（最后注册），它的后置逻辑总能执行
- 如果在 B 中调用
c.Abort()，C 和路由函数都不会执行，但 B 的后置逻辑也不会执行（只有已进入的 A、B 前置部分 + A 后置部分）
Use() 注册位置决定作用域
Use() 方法既能在 *gin.Engine 上调用（全局），也能在 *gin.RouterGroup 上调用（局部）。关键不是“用了没”，而是“在哪用的”。
- 全局
r.Use(mw)：所有路由（包括 404、静态文件）都会经过，适合日志、监控、跨域 - 分组
admin := r.Group("/admin"); admin.Use(authMW)：仅该分组下路由生效，适合权限隔离 - 单路由
r.GET("/x", mw1, mw2, handler)：只对该 endpoint 生效，适合特殊校验或调试钩子 - 注意：
gin.Default()内部已调用engine.Use(Logger(), Recovery())，重复注册会导致日志打两遍
c.Set()/c.Get() 是跨中间件传数据的唯一安全方式
中间件之间不能靠闭包变量共享状态（goroutine 不安全），也不能靠全局变量（并发污染）。唯一推荐方式是通过 c.Set(key, value) 和 c.Get(key)。
-
c.Set()存的是map[interface{}]interface{}，key 类型建议用string或自定义类型（避免字符串冲突） - 值对象必须是线程安全的；若存指针或 map/slice，需自行保证读写互斥
-
c.MustGet()和c.GetString()是常用封装，但底层仍是c.Get()，不存在“自动 panic”或类型转换失败静默丢数据的情况 - 别把大对象塞进 context——它生命周期只覆盖单次请求，但内存不会立即释放，可能拖慢 GC
c.Next() 的调用时机和 c.Abort() 的副作用边界。很多 bug 来自以为“中断了流程”，结果后置逻辑仍在执行，或者误判了 abort 后 context 的可用性。 
