企业级系统的权限设计往往是项目初期最容易被低估的环节。等到业务复杂起来才发现能登录和能看对数据完全是两码事。JeecgBoot 把 RBAC 模型做进了低代码平台里但配置得当需要理解几个关键关联。这篇结合一个真实场景把角色菜单和数据权限的配法彻底讲透。RBAC 在 JeecgBoot 中的实体关系JeecgBoot 的权限体系围绕四个核心实体展开用户、角色、部门、菜单。理解它们的关联方式是后续配置的基础。用户系统的最小操作单元一个用户可以绑定多个角色角色权限的集合载体通过角色间接获得菜单和数据范围部门组织架构的层级体现同时也是数据权限的边界依据菜单功能入口支持细化到按钮级别的控制这四者的关系可以概括为用户通过角色获得菜单操作权通过部门归属获得数据可见范围。JeecgBoot 在sys_user、sys_role、sys_depart、sys_permission几张核心表中维护这些关联前端渲染菜单时做交集计算后端接口层面再做二次校验。第一步创建角色并分配菜单权限假设我们要为区域运营专员这个角色配置权限完整流程如下。创建角色进入系统管理 → 角色管理点击新增。角色编码建议采用语义化命名比如regional_ops方便后续在代码中识别。角色名称填写区域运营专员选择状态为正常。分配菜单权限在角色编辑页切换到权限配置标签页。这里会出现完整的菜单树勾选时需要注意两个层级菜单级控制左侧导航是否可见。勾选父级会自动全选子级但建议根据实际业务逐层确认避免过度授权。按钮级展开具体菜单节点后会出现新增编辑删除导出等按钮权限。这是很多企业容易遗漏的点——只给了页面入口没给操作按钮用户进去只能干瞪眼。按钮权限的开启位置在菜单管理 → 具体菜单的按钮权限标签页预先定义好操作标识比如user:add、user:edit。角色配置时这些标识会以复选框形式呈现。数据权限的开启位置同样在角色编辑页找到数据权限下拉选项。JeecgBoot 内置了四种数据范围全部数据本部门数据本部门及以下数据仅本人数据这里先选择本部门数据下一节会详细展开部门经理的场景配置。配置完成后建议立即用测试账号登录验证先看菜单是否出现再点进去看按钮是否显示最后尝试越权访问接口看是否被拦截。第二步配置部门经理的行级数据权限实际业务中常见的需求是部门经理只能查看本部门的数据而普通员工只能看自己的。JeecgBoot 通过注解层面和配置层面双重控制来实现。场景设定技术部经理能看技术部所有员工的数据技术部员工只能看自己的数据配置层面的控制在角色管理中技术部经理的角色数据权限设为本部门及以下数据普通员工设为仅本人数据。这是第一层过滤由框架自动完成。注解层面的控制在需要数据权限控制的实体查询方法上添加PermissionData注解PermissionData(pageComponent system/UserList) public PageUser queryPageList(User user, Integer pageNo, Integer pageSize) { // 业务逻辑 }pageComponent参数对应前端组件路径框架会根据当前用户的角色数据权限自动在 SQL 中追加WHERE条件。比如技术部经理查询时会附加and depart_id in (技术部id, 子部门id)的过滤。自定义数据权限规则如果内置的四种数据范围不够用比如需要跨部门但限定某些产品线的复杂规则可以在DataPermissionRule接口的实现类中扩展。JeecgBoot 的JeecgDataPermission类提供了切入点重写getSqlSegment方法即可注入自定义条件。这里有个容易踩坑的点注解生效的前提是查询必须走 MyBatis-Plus 的QueryWrapper手写原生 SQL 或自定义 Mapper 时需要自行处理权限过滤。第三步扩展自定义权限规则的 Shiro 介入点JeecgBoot 默认使用 Apache Shiro 做认证授权。如果需要扩展自定义权限规则比如基于项目维度、客户维度的细粒度控制需要在 Shiro 配置中介入。自定义 Realm继承AuthorizingRealm重写doGetAuthorizationInfo方法Override protected AuthorizationInfo doGetAuthorizationInfo(PrincipalCollection principals) { SimpleAuthorizationInfo info new SimpleAuthorizationInfo(); // 获取当前用户 LoginUser user (LoginUser) principals.getPrimaryPrincipal(); // 加载角色 SetString roles userService.getUserRoles(user.getId()); info.setRoles(roles); // 加载权限含自定义规则 SetString permissions permissionService.getUserPermissions(user.getId()); info.setStringPermissions(permissions); return info; }配置 Shiro 过滤器链在ShiroConfig中将自定义 Realm 注册到SecurityManagerBean public DefaultWebSecurityManager securityManager() { DefaultWebSecurityManager manager new DefaultWebSecurityManager(); manager.setRealm(customRealm()); // 其他配置... return manager; }自定义权限注解对于无法通过角色或菜单表达的业务规则可以定义自定义注解配合 AOP 切面在方法执行前做权限校验。比如ProjectPermission(projectId #projectId)通过 SpEL 表达式解析参数再查询当前用户是否有该项目的操作权。两种开发方式的维护成本对比权限需求在项目生命周期中频繁变动是常态。对比纯代码开发与平台配置两种方式维度纯代码开发JeecgBoot 平台配置新增角色改代码、发版、重启界面点选即时生效调整菜单权限修改注解或配置文件角色管理界面勾选数据规则变更重写 SQL 片段或切面逻辑修改角色数据权限选项审计追溯需自行实现操作日志内置权限变更记录显然对于频繁调整的权限需求平台配置的效率优势明显。但也要注意边界当权限规则复杂到需要大量自定义代码时维护成本会陡增。建议把常见模式部门隔离、个人隔离交给平台特殊规则通过扩展点实现保持两者的平衡。多租户场景的额外注意项如果系统采用 SaaS 多租户架构权限隔离需要额外关注两点租户间的数据隔离JeecgBoot 的多租户实现中sys_tenant表与核心权限表存在关联。配置角色时确保tenant_id字段正确赋值避免租户 A 的角色被租户 B 的用户误用。框架在查询时会自动追加租户条件但初始化数据时需要校验。超级管理员与普通租户的权限差异平台超级管理员能跨租户操作这个角色的数据权限建议设为全部数据但在具体业务实现中跨租户查询需要显式指定租户 ID不能依赖框架的自动注入。否则可能出现超级管理员查看数据时因缺少租户过滤而返回全量数据的性能问题。权限配置没有一劳永逸的方案但理解框架的设计意图后可以少走很多弯路。建议每次调整权限后用不同角色的测试账号完整走一遍业务流程特别是边界场景——比如部门经理离职交接、员工跨部门调岗时的数据可见性变化。