权限分级必须靠中间件链，不能塞在控制器里；RBAC需依赖iris-admin的permRoutes运行时结构，JWT解析后须手动查权限映射，路径注册须与路由定义完全一致（含版本前缀和参数类型）。
权限分级必须靠中间件链，不能塞在控制器里
很多人写个 if !hasRole("admin") 放在 controller 方法开头就以为完事了，结果测试发现 /v1/user/delete 这种敏感接口，未登录用户也能进到数据库操作层。Iris 的路由匹配和中间件执行是分离的，controller 层根本不是权限拦截的第一道门。真正起作用的是 Party().Use() 或 app.Use() 注入的中间件链——它在任何 handler 执行前就已启动。
常见错误包括：
- 把鉴权逻辑写在
BeforeActivation里：这只影响单个 handler，无法覆盖整个分组 - 只注册一次中间件却期望它自动识别 v1/v2 版本差异：版本分组不自动隔离中间件，
/v1和/v2必须各自挂载对应权限策略 - 用
ctx.Next()却没处理后续失败分支：比如角色校验失败后只返回 JSON，但没调ctx.StopExecution()，导致 controller 仍会执行
RBAC 权限判断得依赖 permRoutes 运行时结构
Iris 自身不带权限路由表，iris-admin 提供的 permRoutes 是关键。它不是配置文件，而是一个在启动时注册的内存映射：每个条目包含路径、HTTP 方法、允许的角色列表和可选的附加中间件。如果你只解析出用户角色（比如从 JWT 拿到 "role": "editor"），但没把 POST /api/posts 映射到 ["admin", "editor"]，那这个请求照样被拒绝。
注册方式必须用 admin.RegisterPermissionRoute()，不能靠注释或约定。示例：
admin.RegisterPermissionRoute("/api/users", "POST", []string{"admin"}, nil)
admin.RegisterPermissionRoute("/api/users/{id}", "GET", []string{"admin", "user"}, nil)
注意：permRoutes 不支持运行时动态增删，所有权限规则必须在 app.Run() 前完成注册。
JWT 解析后必须手动查 permRoutes，不能只比对角色字符串
拿到 token 后解析出 claims.Role 只是第一步。很多团队卡在这儿：以为只要 claims.Role == "admin" 就能放行，结果发现 GET /api/logs 被 user 角色绕过了——因为这个接口根本没在 permRoutes 里声明，或者声明时漏写了 GET 方法。
正确流程是：
- 从
ctx.Values().Get("user")取出解析后的用户信息（需确保鉴权中间件已存入） - 调用
admin.HasPermission(claims.Role, ctx.Request().Method, ctx.Request().URL.Path) - 失败时立即
ctx.StatusCode(iris.StatusForbidden)+ctx.StopExecution() - 不要复用 JWT 中间件里的
ctx.Next()逻辑，RBAC 校验是独立一层
多版本 API 的权限策略容易错配路径参数类型
/v1/user/{id} 和 /v2/user/{id:uint64} 看似一样，但 Iris 的路由树匹配是精确的。permRoutes 查找依赖完整路径字符串，如果 v1 的路由定义没声明类型，ctx.Params().GetUint64("id") 会 panic；如果 v2 强制了 {id:uint64}，但 permRoutes 里注册的还是 /v2/user/{id}（没带类型），查找就会失败，导致权限永远不匹配。
解决方案只有两个：
- 所有版本路由定义必须显式声明参数类型，比如统一用
{id:uint64} -
permRoutes注册路径必须和实际路由定义完全一致，包括类型后缀 - 测试时用 curl 直接打
GET /v1/user/abc，确认返回 404（路由不匹配）而非 403（权限拒绝），才能说明路径定义和权限注册对齐
最易忽略的是：v1 和 v2 共享同一套 permRoutes 注册逻辑时，路径字符串拼接容易漏掉版本前缀，比如注册成了 /user/{id:uint64} 而不是 /v2/user/{id:uint64}。
