这个 RBAC 后台项目，适合拿来直接做业务起步
如果你正在找一套能真正落地的后台权限系统骨架，可以看看 rbac-soli-admin。
GitHub 仓库地址：
https://github.com/qianglizheng/rbac-soli-admin
这个项目不是那种只适合演示、改起来却很痛苦的后台模板。它更像一套已经把权限后台核心链路打通、适合继续接业务模块的基础工程。
现在这套工程已经具备一批后台系统最常用、也最关键的能力：
- 登录认证
- 仪表盘
- 用户管理
- 角色管理
- 菜单管理
- 字典管理
- 参数配置
- 基于菜单的动态路由
对一个准备启动内部管理系统、业务运营后台、权限平台或者中台管理端的团队来说，这些能力不是装饰，而是最先要站稳的部分。
项目截图
登录页
首页
用户管理
菜单管理
为什么很多后台项目最后不好用
很多开源后台工程的问题，不是不能跑，而是不适合继续做事。
常见情况通常是：
- 页面很多，但核心链路并不清楚
- 功能看起来完整，真实改造成本却很高
- 项目结构越来越重，后续业务模块很难接入
- 模板感太强，真正上线前还得推翻重做
所以一个后台项目真正有价值，不在于一开始堆了多少页面，而在于接手之后，能不能快速改、持续改、长期维护。
rbac-soli-admin 更重视后者。
这个项目适合什么场景
1. 作为公司内部后台的起步工程
很多团队并不需要一上来就引入一整套复杂平台，但一定需要一套明确的权限底座：
- 谁能登录
- 谁能看哪些页面
- 谁能操作哪些功能
- 菜单和权限如何对应
- 系统参数和字典数据如何统一管理
这套工程已经把这些基础能力搭起来了，适合继续往上接采购、仓储、审批、主数据、客户、订单这类业务模块。
2. 作为 RBAC 权限模型的学习项目
如果你正在学 Vue 3、Spring Boot、Spring Security，或者想真正看懂一个 RBAC 后台是怎么从登录、角色、菜单、动态路由一路串起来的，这个项目也很适合拿来拆着看。
它的重点不在炫技，而在把一条核心链路讲清楚：
- 前端如何根据菜单动态生成路由
- 后端如何基于用户身份和角色返回菜单树
- 用户、角色、菜单三者如何形成一套实际可用的权限结构
3. 作为继续演进的开源项目
它现在已经不是空壳，而是一套可以继续往前长的基础工程。
比较容易形成高质量贡献的方向包括：
- 补充接口文档和使用文档
- 增加 Docker、CI、Maven Wrapper
- 完善测试和初始化数据
- 扩展组织架构、数据权限、审批流等通用模块
- 优化前端交互、视觉和表单体验
- 提升后端模块边界和工程规范
这套工程真正有价值的地方
能启动的后台项目很多，但能直接成为业务起点的并不多。
rbac-soli-admin 的价值主要在这几个地方：
- 前后端是分离的，适合独立迭代
- 系统管理能力已经具备，不用从零搭权限壳子
- 核心模块比较集中，后续扩展方向明确
- 代码结构偏实用，不是只为演示写的页面拼装
这意味着它适合做两类事：
- 快速起一个自己的后台项目
- 在现有骨架上持续扩展成团队内部系统
当前技术栈
前端技术栈：
- Vue 3
- Vite
- TypeScript
- Pinia
- Vue Router
- Element Plus
后端技术栈：
- Java 21
- Spring Boot 3
- Spring Security
- MyBatis
- MySQL
- Redis
- MapStruct
这套组合有两个很现实的优势：
- 生态成熟，开发者容易接手
- 后续招人、交接、扩展都比较稳
如果你准备直接拿来用
这个项目比较适合作为下面几类系统的起点：
- 企业内部管理后台
- 带权限控制的业务运营平台
- 中后台基础脚手架
- Vue + Spring Boot 全栈学习项目
如果你准备直接落业务，接下来最适合继续补的模块通常会是：
- 部门管理
- 岗位管理
- 组织架构
- 数据权限
- 审批流
- 业务单据模块
这些方向和当前工程的结构是相容的，不需要推翻重来。
开源协议
这个项目采用 MIT License。
这意味着：
- 个人可以直接使用
- 企业可以直接使用
- 允许免费商用
- 允许修改、分发和二次开发
如果你要把它作为自己项目的起点，或者接进公司内部系统，从协议上没有障碍。
最后
一个后台项目真正难的，不是做出几个页面，而是把登录、权限、角色、菜单、系统配置这些基础设施做成一个后面还愿意继续维护的工程。
rbac-soli-admin 现在已经具备了这样的雏形。
如果你想找一个可以继续扩展的 RBAC 后台基础工程，可以直接看仓库：
https://github.com/qianglizheng/rbac-soli-admin