最火后台管理系统 RuoYi 项目探秘，之一

我们正在探秘各种比较火热的后台管理相关的开源项目，探秘结果将以系列文章的形式分享。希望你能在这些文章中学习别人的优点，也能看到别人的不足，进而可以提升自我的技术能力或技术态度，不论是提升了什么，只要你有收获即可。

“你若不离不弃，我必生死相依”，是一句非常痴情的话，也常被人化用于孩子的名字，寄托父母美好的期望。

今天要探的这个最火后台管理系统 RuoYi（若依），便是作者化用女儿的名字命名的项目。

项目介绍

RuoYi 主要在 Gitee 上维护，GitHub 也有同步项目，项目地址分别为：Gitee，GitHub。

截止 2022.10.18，该项目版本为 4.7.5，在 Gitee 上收获点赞 3万2千5百 次，被"抄作业" 1万7千3百 次，还被 5千2百 人关注；在 GitHub 上则收获点赞 3千 次，被"抄作业" 988 次，还被 62 人关注。

如此高的热度，一定是有它的原因的。今天我们便来一探究竟。

看装修

用 IDEA 打开项目后，目录结构如图：

其中纯目录如下：

• .github：隐藏的 GitHub 相关配置文件，打开一看，可以看到作者的恰饭链接。果然恰饭得随时恰才行。
• bin：里面有三个脚本 clean.bat、package.bat、run.bat，应该是清理、打包和运行脚本。
• doc：里面有一个 word 文档，名为 《若依环境使用手册.docx》。

子项目目录则分为：

• ruoyi-admin：见名识义，我们推测项目应该管理相关功能模块
• ruoyi-common：此项目推测为常用工具类、基础组件相关模块
• ruoyi-framework：此项目应该为核心框架层面
• ruoyi-generator：此项目可能是一种生成器工具
• ruoyi-quartz：quartz，照这个标准名字，推测此项目为定时器或定时任务相关模块
• ruoyi-system：由于上面有 framework 项目了，推测此项目为一些非业务功能的底层模块
• sql：项目的数据库、表定义及初始化数据 sql 文件。

另外根目录下还有两个脚本 ry.bat 和 ry.sh，由于上面 bin 目录中已有打包运行的整套脚本了，那么这两个脚本应该是 Windows 和 Linux 环境下的本地运行脚本。

从目录整体看的话，项目拆分中规中矩，但是在根目录和 bin 目录中都有脚本，显得有点凌乱，对于刚打开项目的我来说，我会不太明白这些脚本的用途。如果根目录中放脚本，是为了方便调试时更快的找到脚本，但脚本并不比 IDEA 本身直接 Run/Debug 方便；如果是为了验证 jar 的运行情况，那其实倒可以归整到 bin 目录中，再在里面区分为子目录 Release 和 Debug。

但一千人眼里有一千个哈姆雷特，我和作者的眼里也会有不同的设计考虑，没有对错之分，也许只是我没有领会到他的目的。

看菜单

表面的目录结构看完了，要了解一个项目，还需要知道它是怎么运行起来的，在项目根目录中我们看到一个老朋友 pom.xml，这个老朋友告诉我们：这个项目的包管理器是 Maven。那么打开这个 pom.xml，我们就知道项目有些什么东西，地道不地道了，到底是不是正经厨子的作品。

pom.xml 配置项折叠后：

像图中一样，我们将 pom.xml 二级子项折叠后，可以看到子项之间的空行有多有少，可能作者没有代码洁癖，但强迫症患者则会表示看着真难受。

从第一部分项目基本信息中，如图：

可以看到，项目目前已是 4.7.5 版本，项目的网站地址为：http://www.ruoyi.vip。

第二部分的属性定义，如下图：

一般我们会将所有引用的包的版本信息都统一配置在 properties，所以直接看属性配置，基本就能掌握所有引用的包的信息。

如图中所示，我们可以看到 RuoYi 项目中使用了并不太多的开源项目，正如项目描述中所说的一样“ 核心技术采用 Spring、MyBatis、Shiro，没有任何其它重度依赖”。确实如作者所说，这份硬菜里没有掺水。

我们在属性中，首先就看到了 Shiro，项目整体的 RBAC 应该是基于 Shiro 构建的，接着，我们看到 thymeleaf-extras-shiro，这个是一个将 Shiro 与 Thymeleaf 相结合的工具，也说明当前主项目不是前后端分离的开发模式，前端 Web 界面还是使用模板引擎 Thymeleaft 解析的。

再往下，我们看到 Druid，说明作者采用了 Alibaba 的 Druid 作为数据库连接池，Alibaba 早就把此项目捐赠给了 Apache，所以如果你搜索 Druid，最终一定会来到 Apache 的网站：https://druid.apache.org/。

然后我们发现属性中有一个 bitwalker.version，这是项目中比较少见的一个组件，我们找一下对应的包，发现其为：eu.bitwalker:UserAgentUtils，官网为：https://www.bitwalker.eu/software/user-agent-utils。官方介绍：“The user-agent-utils java library can be used to parse HTTP requests in real-time or to analyze log files and gather information about the user-agent”。意思就是说这个是用于处理浏览器 User-Agent 数据的工具组件。这个工具一般项目还是很少用的，不知道作者用它解决了什么问题。

再往下，看到有一个 kaptcha，它所对应的是 com.github.penggle:kaptcha，项目地址为 https://github.com/penggle/kaptcha。这是一个验证码生成工具组件，但是这个项目发布的包是 2015 年发布了，7 年啦，孩子都上小学了。这个组件已经存在两个安全漏洞了，个人建议最好替换为更好用更安全的组件。

下面是常规的用于 Restful API 文档生成的 swagger。还有操作数据库的“半 ORM”框架 mybatis，以及适配给 mybatis 用于分页查询的 pagehelper，这两者经常一起搭配使用，用于数据库层面常见的分页查询业务。

在 pagehelper 下面，是我们绕不开的 json 工具组件，作者选用了 fastjson。fastjson 作为 Alibaba 的一个开源组件，特点在于操作 API 简洁，一般情况下性能比较好，但这几年 fastjson 爆了很多安全漏洞，而且对于稍微复杂一点的 json 需求无法解决，各家企业都开始去除 fastjson。建议为了项目的运行安全，如果可以的话，不要使用 fastjson，推荐还是使用老牌的 com.fasterxml 家的 jackson。

接着，properties 配置中倒数还有几个组件。第一个 oshi 比较有趣，这个对应的组件为： com.github.oshi:oshi-core，这个组件项目地址为：https://github.com/oshi/oshi。这个组件用途是获取本地操作系统及硬件的信息，很好奇 RuoYi 用这个是实现了什么设计，道理上讲，不可能只是会了展示一下用户操作系统及硬件就完了。

剩下的 commons-io 是我们常用的 I/O 工具组件，多用来处理文件的读写或者 URL 数据的解析等，项目地址:https://github.com/apache/commons-io；而 commons-fileupload 是我们常用的文件上传工具组件，项目地址：https://github.com/apache/commons-fileupload；poi 则是常用的 Office 文件处理工具组件，作者选用了 OOXML 用于处理 Excel 表格文件，应该是有相应的业务需求，项目地址：https://github.com/apache/poi。

以上这几个都是 Apache 的开源项目，Apache 的项目不一定是最好用的，但质量一定是有基本保证的。

通过以上的分析过程，我们直接通过 properties 的定义就大概掌握了 RuoYi 项目所使用的开源组件的全貌。咦，等等，好像有一个很重要的遗漏了……是的，就是项目的核心框架 Spring Boot 遗漏了。我去……

我去 dependencies 看看，第一个就是它。如图：

原来作者没有将 Spring Boot 的版本定义到 properties 里，属实有点怪异。建议有洁癖的人，还是把这些版本统一定义，要不然真的难受。我们可以看到作者使用的 Spring Boot 版本为 2.5.14，目前官方的最新版本为 2.7.4，作者先用的版本还是比较新的。

试吃

分析了 pom.xml 中的开源组件情况，大致相当于了解了一家饭店的拿手菜以及常用的烹饪技法。接下来我们就要开始试吃这家店，对于项目而言，我们现在就要先把项目运行起来，看看它的实际效果如何。

我们去 ruoyi-admin 找一找，很快就可以找到启动类 RuoYiApplication，如图：

我们可以看到，这里面除一行注释掉的无用代码外，有一行启动代码，然后还有一个使用 System.out.println 在控制台输出的 banner 字符画。作者还是很有情调的。但感觉有点不对呢，Spring Boot 不是提供了标准的 banner 输出方式吗？作者可能会不知道？？我不信，赶紧找一找。果然有 resources 目录下发现 banner.txt。如图：

果然作者是知道的，他就是想输出两个 banner！

不过，对于有洁癖的人来说，无用的代码就不要保留了，显得很不干净。

再细看一眼，咦，RuoYi 不是 Java 项目么，为啥这个一对大括号是前对齐呢，这不是 C# 的代码风格么？我去……

我去快捷键格式化一下，再把注释代码移除一下，如图：

舒服了。建议团队协作的开发者或者有洁癖的人，还是按语言特性对齐大括号，要不然风格不一致会让人感觉非常不适。

一切准备就绪，点击 Run！翻滚吧，牛宝宝！！

果然，正如以前经历的万千情况一样，数据库无法连接，乖乖按文档先把数据库建好，再次点击 Run！牛宝宝，翻滚吧！不行，翻滚前还要吐槽一下，为什么数据库的连接不能使用环境变量来动态指定，一定要写死成 localhost:3306 呢？算了，看看人家 3万 多的点赞，闭嘴吧。

牛宝宝，重新翻滚！

启动成功，控制台输出了作者的字符画，如图：

访问 http://localhost，登录界面如图：

登录进入系统后，系统整体界面如图：

我们可以看到，整个系统功能模块主要分为：

• 系统管理
• 系统监控
• 系统工具

这些功能模块的进一步探秘，我们将在下篇继续。

小结

本篇，我们初探了 RuoYi 项目的大体结构以及主要依赖的开源组件。RuoYi 项目结构划分中规中矩，核心开源组件是常见的 Spring Boot、Shiro 和 MyBatis，工具组件使用的基本是 Apache 家族的，还有个别比较老旧的小组件。大厂家的组件安全性有保证，我们如果自己开发项目，尽量选择大厂家的开源组件，并尽量选择安全漏洞少的组件，可以有效减少产品交付后由于安全漏洞导致的版本升级、安全补丁发布等事情。

从 pom.xml 和 启动类，就可以看到作者的代码风格不好。建议项目开发中，我们要使用对应开发语言约定俗成的风格，并且我们还是要有点技术洁癖，不要在代码中用注释来保留那些没用的代码，毕竟 Git 就是帮我进行版本管理的工具。

下一篇，将继续展开 RuoYi 项目的功能模块，并逐一细细品尝各个功能。本篇就到这里，比心，❤。

更多文章，欢迎阅读我的博客阿呜的边程。