我们正在探秘各种比较火热的后台管理相关的开源项目，探秘结果将以系列文章的形式分享。希望你能在这些文章中学习别人的优点，也能看到别人的不足，进而可以提升自我的技术能力或技术态度，不论是提升了什么，只要你有收获即可。
“你若不离不弃，我必生死相依”，是一句非常痴情的话，也常被人化用于孩子的名字，寄托父母美好的期望。
今天要探的这个最火后台管理系统 RuoYi（若依），便是作者化用女儿的名字命名的项目。
# 项目介绍
RuoYi 主要在 Gitee 上维护，GitHub 也有同步项目，项目地址分别为：Gitee (opens new window)，GitHub (opens new window)。
截止 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 (opens new window)。
第二部分的属性定义，如下图：
一般我们会将所有引用的包的版本信息都统一配置在 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/ (opens new window)。
然后我们发现属性中有一个 bitwalker.version，这是项目中比较少见的一个组件，我们找一下对应的包，发现其为：eu.bitwalker:UserAgentUtils，官网为：https://www.bitwalker.eu/software/user-agent-utils (opens new window)。官方介绍：“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 (opens new window)。这是一个验证码生成工具组件，但是这个项目发布的包是 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 (opens new window)。这个组件用途是获取本地操作系统及硬件的信息，很好奇 RuoYi 用这个是实现了什么设计，道理上讲，不可能只是会了展示一下用户操作系统及硬件就完了。
剩下的 commons-io 是我们常用的 I/O 工具组件，多用来处理文件的读写或者 URL 数据的解析等，项目地址:https://github.com/apache/commons-io (opens new window)；而 commons-fileupload 是我们常用的文件上传工具组件，项目地址：https://github.com/apache/commons-fileupload (opens new window)；poi 则是常用的 Office 文件处理工具组件，作者选用了 OOXML 用于处理 Excel 表格文件，应该是有相应的业务需求，项目地址：https://github.com/apache/poi (opens new window)。
以上这几个都是 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 项目的功能模块，并逐一细细品尝各个功能。本篇就到这里，比心，❤。