必须按 Group 挂中间件，因 r.Use() 全局注册会导致 v1/v2 权限逻辑混乱、重复解析 token、abort 冲突；应通过 c.FullPath() 动态提取版本并查策略，或集成 Casbin 实现外置 RBAC 控制。
直接挂 r.Use() 会破坏版本隔离，权限逻辑必然失控——必须按 Group 挂中间件，且中间件内部不能硬编码版本判断。
为什么 r.Use(AuthMiddleware()) 会导致 v1/v2 权限混乱
全局注册中间件会让所有路由（包括 /v1/users 和 /v2/orders）强制走同一套校验逻辑。但真实场景中，v1 可能只允许 user 角色访问，而 v2 要求 admin 才能调用。全局中间件无法区分路径上下文，更没法动态查策略。
更危险的是叠加使用：比如先 r.Use(AuthMiddleware())，再 v2.Use(AdminOnlyMiddleware())，会导致 token 被重复解析、header 被重复写入，甚至 c.Abort() 冲突，最终返回 401/403 混乱。
- 所有版本路由必须严格通过
Group()组织，禁止在 Group 外定义同前缀的独立路由（如r.GET("/v1/:id", ...)），否则会贪婪匹配子路由导致 404 - 中间件必须挂载在
Group上，而非根引擎或单个路由 - 不要为每个版本写一个中间件函数，应统一入口，运行时解析路径
如何从请求路径动态提取版本并校验角色
中间件不应假设当前是 v1 还是 v2，而要主动识别。Gin 提供 c.FullPath()（已处理路由参数），比 c.Request.URL.Path 更稳妥。
推荐做法是用 strings.HasPrefix(c.FullPath(), "/v1/") 判断归属，再查对应策略表，例如：
v1Policy["/users"] == []string{"user", "admin"}v2Policy["/orders"] == []string{"admin"}
用户角色应由前置中间件注入上下文（如 c.Set("role", "user")），本中间件只负责读取 c.GetString("role") 并比对策略。不满足时直接调用 c.AbortWithStatusJSON(403, gin.H{"error": "forbidden"})，避免 c.JSON() + c.Abort() 分两步漏 abort。
用 Casbin 实现策略外置的 RBAC 控制
当权限规则变多、角色变复杂时，硬编码策略表难维护。Casbin 是轻量级替代方案，支持 ACL/RBAC/ABAC，策略可存 CSV 或数据库。
典型集成链路是：JWT 中间件 → 解析 token 并写入 <code>c.Set("userID", uid) → Casbin 中间件 → 调用 e.Enforce(userID, c.FullPath(), c.Request.Method) → 返回布尔值决定是否放行
- Casbin 模型文件（
rbac_model.conf）定义规则结构，策略数据（policy.csv）描述具体映射，两者分离便于热更新 - 注意：Casbin 不自动识别版本前缀，仍需你自己从
c.FullPath()提取资源名（如去掉/v2/后取orders），再传给Enforce() - 性能上，Casbin 内存加载策略后单次判定耗时在微秒级，无需缓存层
容易被忽略的上下文污染和 abort 时机
中间件链中，如果前置中间件已调用 c.Abort()，后续中间件仍会执行——除非你显式检查 c.IsAborted()。这会导致日志重复打、DB 查询冗余、甚至 panic（比如试图从空上下文取 "role"）。
另一个坑是上下文 key 冲突：c.Set("role", ...) 和 c.Set("user_id", ...) 若被多个中间件随意覆盖，后续校验可能拿到错误值。建议统一用结构体封装，如 c.Set("auth", AuthContext{Role: "admin", UserID: "u123"})，再用类型断言安全读取。
最常出问题的不是策略逻辑本身，而是 abort 没写对、上下文没清理、路径解析没用 FullPath——这些细节一错，整个权限系统就形同虚设。
