Gin 中不同 API 版本必须使用独立 Group 实例注册并显式绑定对应中间件，禁止复用 group 变量或中间件 slice；中间件应职责单一、版本专属，避免运行时版本判断，确保上下文契约一致且配置驱动启用。
用 gin.Group 分别注册版本组，再各自调用 Use
不同版本 API 必须走独立的 Group 实例，不能共用一个 group 变量或复用中间件 slice。Gin 的 Use 是绑定到该 group 实例的中间件链，不会跨组污染。
-
v1 := r.Group("/v1")和v2 := r.Group("/v2")是两个完全隔离的路由组，各自维护自己的中间件列表 - 必须显式调用
v1.Use(authV1Middleware)和v2.Use(authV2Middleware)，哪怕逻辑目前一样，也不能只写一次然后赋值给两个变量 - 中间件函数本身要能区分上下文：比如
authV2Middleware里检查的是X-2FA-Token，而authV1Middleware只校验Authorization: Bearer，混用会直接导致 v1 用户被 v2 规则拦截
中间件内部别硬编码版本判断逻辑
不要在中间件里写 if strings.HasPrefix(c.Request.URL.Path, "/v2/") 或 c.GetHeader("X-API-Version") == "v2" 来动态切换行为——这会让中间件失去可测试性，也违背了“版本路由应在注册阶段确定”的原则。
- 每个中间件应只服务一个明确版本，职责单一。例如
rateLimitV2就只管 v2 的配额策略，不感知 v1 - 如果 v2 新增了双因素校验，就新建
twoFactorAuthMiddleware并只挂到v2组上，而不是在旧的authMiddleware里加 if 分支 - 中间件中读取的 context key（如
c.GetString("user_id")）也应按版本约定，避免 v1 handler 拿到 v2 中间件塞进去的结构体字段
禁止在 handler 里重复解析版本再选中间件
常见错误是把中间件逻辑下放：先注册一个通用 group，再在每个 handler 开头手动判断版本、调用对应鉴权函数。这等于把中间件的责任退回到业务层，破坏了 Gin 的洋葱模型。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 所有鉴权、限流、日志等横切逻辑，必须在进入 handler 前完成。否则
c.Abort()时机失控，错误响应可能绕过全局错误处理中间件 - 若需共享部分逻辑（如日志格式），可提取为无状态工具函数，但不要把它包装成“通用中间件”后塞进两个 group —— 日志字段名、采样率、上下文键都可能因版本而异
- 调试时你会发现：v2 的 429 响应里带着 v1 的 trace_id 格式，就是因为日志中间件没分版本，复用了老字段名
环境变量或配置驱动中间件启用开关
某些中间件只在特定版本生效（比如 v2 才开启审计日志），但又不想写死在代码里。这时应靠启动时条件注册，而非运行时 if 判断。
立即学习“go语言免费学习笔记（深入）”；
- 在
main()函数里，根据配置决定是否调用v2.Use(auditLogMiddleware)，而不是在中间件内部读配置 - 配置项建议用明确布尔值，如
ENABLE_V2_AUDIT_LOG=true，避免用字符串匹配或嵌套 JSON 解析 - 注意：
r.Group()和.Use()必须在r.Run()之前执行完毕；运行时调用会 panic，且新注册的中间件对已建立连接无效
user_id string，v2 改成 user *UserV2，但 handler 里如果还用 c.GetString("user_id") 就会空指针。这种类型错位不会报编译错误，只有压测时突然崩。 
