Revel框架需自行实现RBAC，推荐在Controller Init中显式调用CheckRolePermission函数校验权限，结合Redis缓存、路由注释标记权限、模板透传perms及DAO层强制数据范围过滤。
Revel 框架本身不内置 RBAC 权限系统，必须自己实现角色-菜单-接口的三层校验链。直接用 revel.Interceptor 做全局拦截 + 数据库查角色权限是可行路径，但容易漏掉按钮级控制和数据范围隔离。
Revel 中怎么挂载角色权限校验拦截器
不能只依赖 revel.BEFORE 全局拦截，因为 Revel 的拦截器执行顺序不可控，且无法区分路由层级（比如 /admin/user/list 和 /admin/user/export 应该有不同权限粒度）。推荐在每个 Controller 的 Init 方法里显式调用权限检查函数，或封装成自定义 Controller 基类。
- 把权限检查逻辑抽成独立函数，例如
CheckRolePermission(c *revel.Controller, requiredPerms ...string)，内部查 Redis 缓存的role:perms:{role_id}或直连 DB 查询role_menu和role_api关联表 - 避免在
revel.Interceptor里做数据库查询——Revel 的拦截器是同步阻塞的，DB 耗时会拖慢所有请求 - 如果用了 JWT，可在
revel.FILTERCONFIG阶段解析 token 并注入c.Params.Route.Params["role_ids"]，后续 Controller 直接取用，减少重复查库
菜单表与接口权限如何在 Revel 路由中对齐
Revel 的路由定义在 conf/routes 文件里，格式为 GET /api/order/list Application.OrderList，但这个路径本身不是权限标识。你不能直接拿 /api/order/list 当 perms 字段值，因为前端按钮点击可能触发同一个接口但需不同权限（如“导出订单”和“查看订单”共用 list 接口但应分离控制）。
- 权限标识（
perms）建议采用模块:操作格式，例如order:list、order:export、user:freeze，和sys_api.perms字段严格对应 - 在
conf/routes中给每条路由加注释标记权限，例如# perms: order:export，再写脚本自动提取生成权限初始化 SQL，避免人工维护脱节 - 不要让前端传来的
path字符串直接进权限判断——攻击者可伪造 path，必须用预设白名单匹配
Revel 下怎么处理按钮级隐藏与数据范围控制
Revel 模板（.html）里没有类似 Vue 的 v-if="hasPerm('user:edit')" 语法，也不能像 Spring Security 那样用 @Secured 注解控制模板元素。按钮是否渲染，取决于后端是否把权限数组透传到模板上下文。
- 在每个 Action 方法里手动调用
c.RenderArgs["perms"] = userPerms，然后模板中用{{if .perms "user:edit"}}判断（需自定义 template func 支持字符串查找） - 数据范围（
data_scope）不能只靠前端传参过滤，必须在 DAO 层强制拼接 WHERE 条件：比如角色data_scope=2（本部门），就要自动追加AND dept_id = ?，且参数必须来自 session 或 token，禁止信任前端传入的dept_id - 别把
role_ids存进 Cookie 或 URL 参数——Revel 默认不签名这些字段，极易被篡改，要用revel.Session.Set("role_perms", perms)并开启session.cookie.secure = true
最易被忽略的是：Revel 的 Flash 和 Session 默认使用内存存储，重启服务就丢权限缓存；生产环境必须配 Redis，且 role_menu 表变更后要主动清空 role:perms:{id} 缓存，否则新权限不会生效。
