在国内 Java 后台管理领域， RuoYi 几乎已经成了“事实标准”。
但如果你真的深度做过一次权限改造、二次开发、跨平台适配，你大概率也会和我一样，产生一个问题：
”我们到底是在用 RuoYi，还是被 RuoYi 限制住了？”
声明：本文章并没有恶意贬低RuoYi框架，只是发表一下个人的看法，感谢RuoYi框架长时间的免费开源，为开源社区做出的巨大贡献
一、RuoYi的成功，也是它的枷锁
先说一句实话：RuoYi 并不差，它解决了 80% 的通用问题，它为很多个人开发者、小团队、初创公司等提供了方便快捷的途径。
- 用户管理
- 角色管理
- 菜单权限
- 基于 RBAC 的接口控制
这些对 传统单体后台 来说，完全够用。在 部门结构相对扁平、业务模块相对内聚、用户身份相对单一 的场景下，这套模型简洁、清晰，且完全够用。
但时代已经变了，而它的权限模型没有变。
它的“成功”背后，隐藏着四重枷锁：
-
模型僵化，难适应现代业务架构 在多租户 SaaS、平台型产品、复杂组织层级（如集团-子公司-部门）等场景下，传统 RBAC 的角色爆炸问题日益凸显。权限往往需要与数据维度（如所属机构、项目、地域）动态关联，而 RuoYi 静态的角色-权限绑定难以实现 “同一角色，不同数据可见范围” 的细粒度控制。
-
扩展性不足，牵一发而动全身 系统初期围绕 RBAC 的硬编码逻辑，随着业务多样化逐渐渗入各个模块。任何试图引入 ABAC（基于属性的访问控制）或 RBAC 与 ACL 混用的改造，都容易引发大规模重构，导致团队陷入 “改不动，也不敢改” 的窘境。
-
缺乏对“资源”与“环境”的动态感知 现代应用中，权限判断常需结合上下文：时间、操作对象状态、用户所属部门、资源敏感级别等。RuoYi 原生的权限模型缺少对动态策略的支持，往往只能通过业务代码“打补丁”，破坏了系统的纯粹性与可维护性。
-
技术债积累与团队思维定式 许多基于 RuoYi 衍生的项目在早期追求快速上线，将业务逻辑与权限代码深度耦合。随着团队扩大与业务复杂化，这种耦合逐渐转变为 “隐形的架构债务”，限制了团队对微服务、领域驱动设计等现代架构演进的探索能力。
RuoYi 是一把得心应手的“锤子”，但在面对螺丝、卡扣、胶合等多种连接需求时，仍然只用锤子——就显得捉襟见肘了。它代表了某一时代背景下“足够好”的解决方案，却也因其广泛的应用与固化的设计，无形中延缓了许多项目向更灵活、更细粒度、更动态的权限体系演进的速度。
二、传统 RuoYi 权限模型，本质只有一层
RuoYi 采用了经典的 RBAC 模型，其核心逻辑简单而直接：
用户 → 角色 → 菜单 / 权限
在这一体系中，权限被完全等同于菜单结构，形成了强制的一对一映射：
- 页面入口 ≈ 权限标识
- 按钮操作 ≈ 权限标识
- 后端接口 ≈ 权限标识
于是你会看到系统内产生了这样的扭曲：
- 一个普通的“导出按钮”，必须在菜单表中创建为一个虚拟节点
- 每个 API 接口都需要在菜单树中找到一个挂载点
- 没有菜单，就没有权限——即使该权限与界面展示毫无关系
权限的语义，被 UI 结构彻底绑架，这在现代应用开发中逐渐显露出根本性的局限。 这在今天是非常致命的。
权限颗粒度被模型所困，无法自然生长
当你尝试实现以下场景时，问题会集中爆发：
- API 级别的独立权限控制
- UI 组件级的动态显隐
- 数据行级或字段级的访问隔离
- 基于上下文的条件权限（如：仅处理自己部门的订单）
- 动态策略权限（如：工作流节点审批权限）
你会发现： RBAC + 菜单绑定的单层模型，根本兜不住现实业务的复杂性 于是项目开始滑向“魔改”的深渊：
数据库层面：添加各种ext_字段，建立临时映射表
代码层面：在注解上叠加自定义参数，侵入业务逻辑
前端层面：硬编码判断逻辑，权限与组件逻辑深度耦合
最终状态：权限逻辑散落各处，无人敢轻易改动——系统进入维护的深水区
多终端、多平台场景下的灾难性适配
当系统从单一后台演变为多端平台时：
管理后台（PC） ← 传统菜单权限尚可应付
↓
微信小程序 ← 菜单概念开始模糊
↓
移动端App ← 权限与导航彻底解耦
↓
对外OpenAPI ← 菜单模型完全失效
↓
第三方集成 ← 需要独立的权限体系
菜单型权限模型，在多平台架构下成为适配的灾难：
不同终端对“权限”的定义不同（管理 vs 使用 vs 集成）
同一权限在不同平台可能需要不同的表达方式
前端路由与后端权限被迫强耦合
每增加一个终端，就要重新设计一次权限映射
最本质的问题：权限从“能力”退化为“配置负担”
在 RuoYi 的设计哲学中：
- 权限配置不是为了表达系统能力
- 而是为了满足框架的结构要求
这种本末倒置导致:
权限越多 → 菜单树越臃肿 → 配置越繁琐
↓
权限越细 → 角色定义越复杂 → 维护成本指数上升
↓
开发越恐惧添加新权限 → 业务需求被技术债务压制
最终，权限系统不再赋能业务，反而成为业务创新的障碍——开发者在每次添加新功能时，首先要思考的不是“这个功能如何设计”，而是“这个权限如何在现有框架里塞进去”。
这种设计本质上是一种“架构的偷懒”：用 UI 的思维方式解决安全领域的问题，就像用门禁卡系统管理国家机密一样——它能控制谁进入大楼，但无法控制进入后能看哪些文件、能操作哪些设备。
RuoYi 的权限模型服务于一个已经过去的时代，在那个时代里，系统是封闭的，用户是单一的，业务是线性的。但在今天这个开放、多元、动态的数字世界里，我们需要的是能随业务呼吸的权限系统，而不是让业务去适应权限框架的束缚。
三、我们为什么要重新设计一套后台管理框架？
在真实的企业级开发过程中，我们逐渐发现： 问题不在于 RuoYi 做得不好，而在于它代表的是“上一代后台框架的设计思路”。
随着系统规模、团队结构、业务复杂度的变化，传统后台框架逐渐暴露出一些无法忽视的问题： • 权限模型僵化，扩展成本高 • 业务逻辑与权限、菜单强绑定，牵一发而动全身 • 安全能力更多停留在“有”，而不是“体系化” • 对前后端分离、多端接入、微服务演进支持不足
这正是 JunoYi 后台管理系统框架 诞生的背景。
RuoYi解决了“从无到有”的问题，但企业数字化转型面临新挑战：
四大痛点： 权限不够用 - 现代业务需要数据级、条件级权限控制 架构难演进 - 从单体到微服务缺乏平滑过渡方案 安全不体系 - 零散的安全功能无法应对合规要求 多端难统一 - 不同终端需要重复实现权限逻辑
RuoYi的局限： 权限模型绑定菜单结构，扩展必“魔改” 架构耦合度高，拆分微服务如同重建 安全能力停留在“有没有”，缺乏纵深防御 前后端强绑定，多端适配成本高昂
JunoYi的定位： 不是替代RuoYi，而是提供下一代解决方案：
- 分层权限体系 - 界面、操作、数据权限解耦
- 渐进式架构 - 支持从单体到微服务平滑演进
- 体系化安全 - 从认证到审计的完整链条
- 多端友好 - 统一权限模型，适配不同终端
- 开发友好 - 降低复杂权限的接入成本
一句话：JunoYi为企业级应用而生，支持从小型项目到复杂系统的自然生长。
四、JunoYi 后台管理框架整体演示
JunoYi 并不是一个概念框架，而是一套已经完整落地、可直接使用的后台管理系统。
这是一个你 拉下来、跑起来、就能直接二次开发的框架，而不是 Demo。
五、权限不再“绑架”菜单 —— 全新的权限设计演示
在 JunoYi 后台管理框架中，权限不再与菜单进行强绑定，而是被抽象为独立、纯粹的能力标识。
在这里，权限本身只是一个字符串，例如「系统管理」-「权限组管理」-「权限池」
权限不再复杂，权限大道至简——权限标识符仅字符串而已，例如：
system.ui.menu.view
system.ui.user.view
system.api.menu.list
system.api.user.create
权限不关心它被谁使用、作用在哪个界面，它只描述：
- 是否允许看见某个菜单页面。
- 是否允许能看到前端UI组件（包括常见的按钮，使用v-permission指令）
- 是否允许调用某个API接口
- 是否允许读或写某个类对象指定字段
JunoYi 引入了 权限组（Permission Group） 作为权限管理体系的核心载体，而不是传统的「角色中心制」。
权限组的设计理念 • 所有权限字符串统一维护在 权限池 中 • 权限通过 权限组 进行组织与复用 • 权限组可以灵活绑定到： • 用户 • 角色 • 部门
这种设计，使权限体系具备了极强的： • 扩展性 • 组合能力 • 业务适应能力
权限只需要定义一次， 使用方式却可以在不同业务场景中无限扩展。
权限组的可视化管理体验
拖拽式分配权限标识符
权限组支持通过拖拽方式进行权限分配， 无需手动输入权限字符串，大幅降低使用成本。
权限组可以通过拖拽方式，轻松分配权限标识符 权限组所使用到的权限字符标识符，全部来自权限池中的对系统权限的声明：
用户单独分配权限组
在「系统设置」-「用户管理」-「操作」-「分配权限组」可以单独给用户分配指定权限组。
角色分配权限组
同用户分配权限组一样。
部门分配权限组
同上一样。
用户独立权限分配
除了常规权限组分配权限外，这里还考虑到一种特殊场景，某个用户单独需要指定权限；在这里，如果某个用户只单独需要一个权限，并不需要单独再创建一个权限组，只需要给用户 分配独立权限
在「系统管理」-「用户管理」-「操作」-「独立权限」中，同样可以使用 拖拽方式 将权限池中声明的权限，分配给用户。
六、通配符权限设计 —— 权限不再碎片化
在传统后台管理系统中，权限往往被拆得极碎： • user:add • user:edit • user:delete • user:resetPassword • ……
随着系统复杂度上升，权限字符串数量呈指数级增长， 维护成本极高，配置体验极差。
JunoYi 在权限模型中引入了 通配符权限机制， 让权限既保持精确，又具备极强的表达能力。
单级通配符 *
单级通配符用于匹配当前层级下的所有权限
sys:user:*
等价于
sys:user:view
sys:user:add
sys:user:edit
sys:user:delete
但不会匹配：
sys:user:role:assign
特点：
- 仅匹配当前层级
- 不影响更深层级的权限
- 适合「模块级完整权限」
多级通配符 **
多级通配符用于匹配当前节点下的所有层级权限。
sys:user:**
可匹配：
sys:user:view
sys:user:add
sys:user:role:assign
sys:user:password:reset
特点： • 覆盖所有子层级 • 适合超级管理员或系统内置权限组 • 避免权限配置遗漏
通配符带来的实际价值 • 权限声明更少 • 权限组配置更直观 • 权限组合能力更强 • 权限结构可自然扩展，而无需改动已有配置
新增权限 ≠ 新增配置负担 这点在中大型系统中尤为重要。
七、权限即时生效 —— 动态权限策略引擎
在传统后台系统中，修改权限后需要重新登录几乎是“行业惯例”。
而在 JunoYi 中，这一问题被彻底解决。
JunoYi 并不是简单地“查一次数据库然后缓存权限”，而是引入了一套 动态权限策略引擎（Runtime Permission Engine），用于在运行时统一计算、装配和校验权限上下文。
权限不直接依赖数据库查询
在 JunoYi 中： • 权限字符串只是规则描述 • 权限组是权限的组织单元 • 用户、角色、部门只是权限组的载体
这意味着：
权限的计算过程 ≠ 每次请求都访问数据库
系统启动或权限发生变更时，会将权限数据整理为可快速计算的结构，避免在接口调用阶段进行复杂的 SQL Join 查询。
运行时权限计算，而不是静态授权
JunoYi 的权限校验流程大致如下:
请求进入
↓
解析当前用户的权限上下文
↓
通过权限策略引擎匹配权限规则（支持 * / ** 通配）
↓
快速得出是否允许访问
关键点 • 权限是在运行时动态计算 • 支持权限组继承、叠加、覆盖 • 不依赖固定角色模型（超越传统 RBAC）
Redis 作为权限上下文缓存中心
为了在高并发场景下保证性能，JunoYi 使用 Redis 对权限上下文进行缓存： • 用户 → 权限组集合 • 权限组 → 权限字符串集合 • 预编译后的权限匹配结构
效果： • 避免每次请求查询数据库 • 权限校验可做到接近内存级性能 • 系统整体吞吐能力显著提升
权限变更的实时生效机制
当发生以下行为时： • 修改权限组内容 • 用户 / 角色 / 部门重新绑定权限组 • 权限组继承关系变更
系统会： 1. 更新权限相关数据 2. 刷新 Redis 中对应的权限上下文缓存 3. 通知权限引擎重新加载最新策略
因此： • 已登录用户无需重新登录 • Token 无需重新签发 • 新权限立即参与后续请求校验
前端与后端的协同刷新
• 后端：权限校验实时生效
• 前端：刷新页面即可重新渲染菜单与 UI 权限
这保证了： • 权限一致性 • 用户体验连续性 • 不会因权限调整导致系统“卡死”或“强制下线”
八、总结
JunoYi 后台管理系统框架，并不是在传统后台框架（如 RuoYi）的基础上简单“修修补补”， 而是从权限模型设计这一最核心、最复杂、也最容易失控的部分重新出发， 对整个后台系统的架构方式进行了一次系统性的重构与思考。
在这个框架中： • 权限不再强绑定菜单 • 角色不再是权限的唯一载体 • 权限字符串只是规则描述，而不是结构约束 • 权限组成为真正的权限管理核心 • 通配符权限让权限具备天然的扩展能力 • 权限变更无需重新登录，保存即可生效
这些设计，使得 JunoYi 更适合： • 中大型后台系统 • 多平台、多端统一权限模型 • 长期演进、持续迭代的业务系统 • 对权限精细度和可维护性有更高要求的项目
项目信息
- 项目名称：JunoYi 后台管理系统框架
- 项目定位：面向现代企业与技术团队的全新权限驱动型后台管理脚手架
- 项目介绍：基于 Spring Boot 3 Java 后台管理脚手架框架，内置完善的基础设施能力，面向企业级业务场景设计。支持多端接入，一套代码多端适配；权限与菜单彻底解耦，推翻传统权限设计，采用 RBAC + ABAC + 权限节点 DSL + 运行时策略引擎，更灵活强大；内置安全机制与接口端到端加密，让开发者专注业务而非基础防护。
- 开源协议：MIT免费开源
项目仓库地址：
Github: github.com/Juno-Yi/Jun… Github配套前端： github.com/Juno-Yi/Jun…
Gitee：gitee.com/juno-yi/Jun… Gitee配套前端：gitee.com/juno-yi/jun…
如果你喜欢这个项目，就顺手给项目作者点个Star吧，免费开源不易，多多支持一下吧！
