简介若依芋道RuoYi-Vue-Pro开发资料包内含源码文档与SQL脚本面向使用该框架的Java后端及全栈开发者解决官方文档分散、上手成本高的问题适合从基础配置到业务模块开发的系统学习。压缩包共194个文件以156个HTML开发指南为主另有35个ZIP资源包、2个SQL脚本和1个XMind思维导图整体约213.98MBHTML详细覆盖交易分销返佣、审批加签减签、审批接入、支付宝支付、短信配置、MyBatis数据库、操作日志、流程设计器BPMN等功能模块SQL用于初始化数据表XMind便于快速梳理框架脉络。预览可见这些HTML文档来自若依芋道官方开发指南按功能模块分类便于检索定位。目前已有990人学习作者强调免费开放、拒绝割韭菜明确原创与版权保护立场同时表达对开源社区某些不良现象的不满。借助该包可快速掌握若依芋道核心功能与常见业务场景的实现思路获得一套完整、可落地的开发参考。1. 若依芋道源码文档加 SQL先别急着买这套东西本来就能自己搭很多开发者在搜索栏敲下「若依芋道源码文档加 SQL」其实是在找一套能直接跑起来的后台管理系统解决方案而市面上确实有不少人把公开的源码、文档和 SQL 打包二次售卖号称「最新完整版」「一对一答疑」价格从几十到几百不等。先说结论若依和芋道这两套东西核心源码、官方文档、初始化 SQL 脚本在开源仓库里都能直接拿到卖家的所谓整合包本质上就是把这几样东西按自己的理解重新排了序。真正值钱的不是那份打包文件而是你能否独立完成「建库、导 SQL、起后端、起前端、二次开发」这一整条链路。本文会把这套链路完整拆开源码和文档怎么对应、SQL 脚本按什么顺序执行、常见坑在哪里、以及如何用 MyBatis-Plus 反向维护自己的表结构。读完你就能自己跑通一个最小系统不用再看任何人脸色。2. 若依和芋道到底什么关系源码、文档、SQL 该看哪一份「若依芋道源码文档加 SQL」这串关键词其实指向的是两套关系密切但技术形态不同的东西若依是经典的快速开发框架芋道是在若依生态基础上做了大量增强的开源实现常见形态是单体增强版和微服务版。很多新手买整合包就是因为分不清这两者的 SQL 脚本能不能混用、文档该以哪份为准。这一章先把关系理清楚后面才不会拿错脚本、改错配置。2.1 若依、芋道、微服务 plus 的关系与选型依据先把几个名字对应到具体形态我用一张表说明它们各自是什么、适合什么场景名称技术形态典型技术栈适合场景若依RuoYi 单体单体应用Spring Boot 2 / MyBatis / Shiro小团队快速做后台管理系统用户量不大部署运维简单ruoyi-vue-pro若依生态增强版Spring Boot / Spring Security / Redis / 多租户需要租户隔离、权限模型更完整的 B 端项目yudao-cloud微服务版Spring Cloud Alibaba / Nacos / Gateway多团队并行开发、服务独立部署的中大型项目若依微服务 plus社区改造版若依 注册中心 网关想从若依单体向微服务过渡的团队选型判断标准其实很简单你们团队几个人、需不需要多租户、有没有独立部署多个服务的运维能力。如果只是 3 到 5 个人做一个内部管理系统单体若依足够如果业务方明确要求不同客户数据隔离那就要选带租户能力的版本如果公司已经有一套 Nacos 微服务基础设施才考虑 yudao-cloud。我见过不少团队一上来就选微服务版结果光 Nacos、Gateway、各个服务的调用链就把人绕晕了最后又退回单体。这里要特别提醒一点不同形态的 SQL 脚本是不能混用的。若依单体的表以 sys_ 前缀为主芋道在若依基础上增加了 system_tenant、system_tenant_package 等多租户相关表yudao-cloud 还会拆分出网关、认证相关的独立库。把若依单体的 SQL 导入芋道库登录都会报错。这和标题里「源码文档加 SQL」的对应关系直接相关也是后面所有操作的前提。2.2 文档体系怎么找官方文档、源码自带文档、二手文档的差别文档这件事上优先级应该是源码仓库自带文档 官方在线文档 二手整合文档。源码根目录一般会有 README.md里面写了环境要求、快速启动步骤、SQL 脚本位置这份 README 就是最权威的第一手资料。SQL 脚本通常集中在 sql 目录下按数据库类型分文件夹比如 mysql、oracle、sqlserver 各自独立。二手整合文档的价值只在于「把散落的信息归拢了」但归拢过程中很容易丢失版本信息。比如某个卖家打包的文档里写「导入 sql 即可」但没说明这份 SQL 对应的是单体版还是微服务版、对应哪个版本号你照着做就会在启动阶段翻车。我一般的做法是先把官方文档里「环境要求」「快速启动」「数据库初始化」三页内容复制成 markdown 存到团队内部知识库然后把自己踩过的坑按「现象-原因-解决」补在后面。这份自己维护的文档才是真正属于你的资产。2.3 若依框架和 JEECG 怎么选别被功能列表带偏搜索热词里经常有人拿若依和 JEECG 对比这确实是选型时绕不开的问题。我做了一个并排对比方便你按自己的项目情况判断对比维度若依系JEECG启动速度导 SQL、改配置、起前后端链路清晰自带在线代码生成器配置项多上手门槛更高前端方案Vue2 / Vue3 都有结构直观内置 Ant Design Vue 组件库样式统一但改起来重权限模型Shiro 或 Spring Security 菜单权限逻辑传统清晰自研用户角色组织体系能力强但理解成本高二次开发自己写 SQL、改 mapper 很顺手Online 表单适合纯配置化复杂业务反而受生成器约束排查问题代码结构简单报错链路短很多能力包在生成器里出问题要先翻生成逻辑结论是如果目标是「老老实实把后台管理系统跑起来并且能长期维护」若依系更稳JEECG 的优势在快速配置后台表单但如果业务逻辑复杂生成器生成的代码会成为你的黑匣子。选型时不要被功能列表带偏要看你自己能不能 Hold 住这套代码的排查链路。3. 源码文档加 SQL把数据库初始化脚本完整跑通不管选哪套方案第一步都是导入 SQL。这一步翻车率极高因为不同版本的脚本结构差异、MySQL 版本差异、字符集差异都会冒出来。这一章按照「建库、导脚本、改配置、验证」的顺序完整走一遍用的都是最常见、最稳妥的做法。3.1 SQL 文件清单和执行顺序源码里 SQL 文件通常不止一个先分清每个文件的用途再决定导入顺序。以若依系最常见的目录结构为例脚本文件作用导入顺序sql/ry_2021xxxx.sql主库脚本创建业务表、菜单表、初始管理员、字典数据第 1 个导入sql/quartz.sql定时任务脚本创建 QRTZ 开头的定时任务表第 2 个导入sql/mysql/ 下的版本化脚本某些增强版按模块拆分如 system、infra 分开按官方文档标注的顺序yudao-cloud 的独立库脚本网关、认证、文件服务各自独立库微服务场景按服务依赖顺序判断脚本是否导入成功的标准很简单查 sys_user、sys_menu、sys_role 这类核心表在不在QRTZ 开头的表有没有。如果主库表都在而定时任务表没有不影响登录但定时任务功能会报错如果连 sys_user 都没有说明导错了脚本或者导入中断了。注意若依单体的脚本和芋道的脚本文件组织方式差别很大芋道会把 system 模块和 infra 模块拆开每个模块有自己的表前缀。导入前先打开脚本文件看 CREATE TABLE 语句里的表名确认前缀是否符合你选的版本。3.2 用 MySQL 执行 SQL 脚本的完整步骤导入操作我用命令行完成比可视化工具更可控。完整步骤如下# 1. 建库统一使用 utf8mb4避免中文乱码和表情符号问题 mysql -uroot -p -e CREATE DATABASE IF NOT EXISTS ruoyi DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; # 2. 导入主库脚本sql 文件在源码目录下按实际文件名调整 mysql -uroot -p ruoyi sql/ry_2021xxxx.sql # 3. 导入定时任务脚本 mysql -uroot -p ruoyi sql/quartz.sql # 4. 验证核心表是否创建成功 mysql -uroot -p ruoyi -e SHOW TABLES LIKE sys_%;这段命令里几个细节值得说明。建库时指定 utf8mb4 而不是默认的 latin1是因为后台管理系统的菜单、字典、用户备注里几乎一定会出现中文utf8mb4 还能兼容 emoji避免后期改字符集的麻烦。使用重定向导入而不是进入 mysql 后执行 source好处是导入过程不会被终端交互打断脚本较大时也不容易半路失败。-uroot -p 会提示输入密码如果服务器上配置了免密登录可以去掉 -p 参数。最后一步 SHOW TABLES LIKE sys_% 只查系统表如果结果里出现 sys_user、sys_role、sys_menu说明主库导入成功。3.3 修改后端数据源配置SQL 导入成功后后端应用才能连上数据库。若依系数据源配置一般在后端模块的 application-druid.yml 文件里核心配置如下spring: datasource: druid: url: jdbc:mysql://localhost:3306/ruoyi?useUnicodetruecharacterEncodingutf8zeroDateTimeBehaviorconvertToNulluseSSLfalseserverTimezoneAsia/Shanghai username: root password: 你的数据库密码 driver-class-name: com.mysql.cj.jdbc.Driver这里面有几个参数是血泪经验换来的缺一个都可能起不来服务。serverTimezoneAsia/Shanghai 必须加否则 MySQL 8 会报时区相关的连接错误报错信息虽然长核心就是 server time zone 无法识别characterEncodingutf8 保证读写中文不乱码zeroDateTimeBehaviorconvertToNull 的作用是把数据库里的 0000-00-00 这类零日期自动转成 null老版本的 SQL 脚本里这种值很常见不加这个参数某些查询会直接抛异常useSSLfalse 是为了关闭 SSL 握手警告本地开发完全没必要开。driver-class-name 用的是 com.mysql.cj.jdbc.Driver这是 MySQL 8 的驱动类名旧驱动类名 com.mysql.jdbc.Driver 在 MySQL 8 下会直接报错。3.4 芋道侧的关键差异多租户表如果你用的是芋道体系除了上面这套操作还要额外注意多租户机制。芋道在若依的基础上增加了租户能力核心区别是所有业务表都带 tenant_id 字段初始化脚本里 system_tenant 表决定了登录后的租户上下文。手动插入一个租户并验证的脚本如下-- 插入新租户注意 package_id 要对应已存在的租户套餐 INSERT INTO system_tenant (id, name, package_id, contact_name, status, create_time) VALUES (1024, 某公司项目X, 1, A同学, 0, NOW()); -- 查询用户时必须带上租户条件否则可能查到所有租户的数据 SELECT id, username, nickname FROM system_users WHERE tenant_id 1024;这段 SQL 的逻辑是先往租户表插入一条租户记录再在查询业务数据时显式加上 tenant_id。很多人拿到芋道的 SQL 脚本后只导入了表结构没插入示范租户结果前端登录时提示「租户不存在」还有人在业务代码里写查询忘了带租户条件导致数据互相串。这是芋道和若依单体最大的使用差异也是一个高频翻车点。另一个容易忽略的是 system_tenant_package 套餐表插入租户时指定的 package_id 必须在套餐表里存在否则该租户的菜单授权会是空的。4. 落地避坑初始化与联调时最常见的 5 个问题这一章把我在实际部署中踩过、以及身边开发者反复遇到的 5 个问题完整列出来每一条都按「现象、原因、解决」的顺序写你可以直接对照排查。4.1 MySQL 8 导入老脚本时报日期默认值错误现象导入 ry_ 开头的初始化脚本时报错 Invalid default value for create_time或者导入成功后插入数据时日期显示为 0000-00-00查询出来一团乱。原因MySQL 8 默认的 sql_mode 包含 NO_ZERO_DATE 和 NO_ZERO_IN_DATE这两个模式禁止表字段默认值或数据中出现零日期而若依系早期的 SQL 脚本里很多 datetime 字段默认值写的就是 0000-00-00 00:00:00。解决导入前临时放宽 sql_mode导入完成后再恢复。命令行操作如下# 临时关闭零日期相关的严格模式 mysql -uroot -p -e SET GLOBAL sql_modeONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION; # 导入脚本 mysql -uroot -p ruoyi sql/ry_2021xxxx.sql需要说明的是SET GLOBAL 只对后续新连接生效所以修改后要重新打开 mysql 客户端执行导入另外这个操作是全局的会影响这台 MySQL 实例上的所有数据库生产环境要谨慎。另一个更稳妥的补救方案是后端 jdbc url 里加 zeroDateTimeBehaviorconvertToNull但那是事后兜底导入阶段还是会报错所以两件事最好都做。4.2 前端代码找不到改错了地方现象想改登录页和菜单翻了半天源码没找到页面文件反而在后端 Java 代码里看到了 HTML 片段最后发现改了一堆没用的地方。原因若依采用前后端分离架构前端代码根本不在后端工程里而是在单独的 ruoyi-ui 目录下。卖家文档里如果没讲清楚这个结构新手很容易把后端工程当成全栈工程去翻。搜索热词「若依前后端分离前端代码在哪里」就是这个问题的典型反映。解决先确认项目根目录下有没有独立的 ui 目录若依单体的前端在 ruoyi-ui芋道的在 yudao-ui 之类的前端工程里。页面文件都在 src/views 下登录页、菜单、布局组件各有对应目录。还有一个判断技巧打开前端工程根目录看到 package.json 就说明找对了没有 package.json 的地方就不会是前端源码。4.3 微服务版启动后 Nacos 一直连接失败现象yudao-cloud 这类微服务版启动时日志不断刷 Nacos registry 连接失败过一会儿服务自动退出。原因没有先启动 Nacos或者 Nacos 的地址、namespace 跟前端工程的 bootstrap.yml 配置不一致。微服务版把配置中心、注册中心全部依赖 Nacos它是整个系统的前置条件不是后端子模块。解决先单独启动 Nacos确认 8848 端口在监听再用浏览器打开 Nacos 控制台能看到登录页然后检查 bootstrap.yml 里的 server-addr 和 namespace这两个配置必须和 Nacos 实例完全一致。注意微服务版的配置分成 bootstrap.yml 和 application.yml 两层Nacos 相关的配置在 bootstrap 层改错文件等于没改。4.4 Vue3 TypeScript 版本跑起来一堆类型报错现象前端工程是 Vue3 TS 版本npm run dev 启动时报大量类型错误控制台红的绿的刷屏页面根本起不来。原因新版模板把类型检查挂进了开发流程而项目自带的依赖版本和你本机的 Node 版本不完全匹配导致 vue-tsc 报出一堆本不该报的错误。解决开发阶段可以用 npx vite 直接启动跳过 vue-tsc 的类型检查让开发服务器先跑起来上线构建时再完整跑 vue-tsc 检查。另一个原则是 npm install 必须使用项目自带的 lock 文件不要手动升级依赖很多类型报错其实来自依赖版本漂移。如果报错集中在某个组件先检查该组件的 defineProps 和 ref 泛型写法绝大多数是基础类型标注问题。4.5 宝塔部署后页面能打开、接口全部 502现象前端打包部署到宝塔后页面能正常打开但登录时接口全部 502或者数据库连接直接报 Communications link failure。原因这类问题通常是三个原因叠加。一是前端打包后的 dist 目录里接口请求路径被写成了 /prod-api而 Nginx 没有把这个路径反代到后端端口二是后端配置的数据库地址是 localhost但宝塔的 MySQL 只监听了 127.0.0.1跨环境访问被拒三是数据库时区和字符集与本地不一致导致时间字段异常。解决Nginx 配置里加一条 location /prod-api 的反代规则把请求转发到 127.0.0.1:8080同时后端接口不需要带 context-path数据库方面确认 MySQL 监听地址和端口后端数据源改成服务器内网 IPurl 参数里补齐 serverTimezone 和 characterEncoding。我一般会先在宝塔的 PHP 环境里用 phpMyAdmin 测试远程连接数据库能连上再排查后端这样能快速定位问题是在数据库还是应用层。5. 不买整合包自己维护 SQL 和文档的路子能够独立导入 SQL 之后下一个要解决的是业务变化时的表结构维护问题。业务一改就要加字段、加表如果每次都手写 SQL既慢又容易漏。这一章讲一个我能跑通的最小方案用工具根据实体类生成建表 SQL同时把文档和脚本纳入版本管理。5.1 根据实体类生成建表 SQL 的最小工具搜索热词「mybatisplus根据java实体类生成创建表的sql语句」说明这是很多人的真实诉求。MyBatis-Plus 的代码生成器一般是反向的从表结构生成实体类反过来从实体类生成建表语句没有现成的官方单按钮方案最常见可靠的做法是自己写一个小的生成器扫描带注解的实体类反射字段拼接 DDL。最小实现如下// 根据实体类生成建表 SQL 的工具类示意实现 public class TableSqlGenerator { // Java 类型到 MySQL 类型的映射按项目需要扩充 private static final MapClass?, String TYPE_MAP Map.of( Long.class, BIGINT, String.class, VARCHAR(128), Integer.class, INT, LocalDateTime.class, DATETIME ); public static String generate(Class? entity) { TableName tableName entity.getAnnotation(TableName.class); if (tableName null) { throw new IllegalArgumentException(缺少 TableName 注解: entity.getName()); } StringBuilder ddl new StringBuilder(CREATE TABLE IF NOT EXISTS ) .append(tableName.value()).append( (\n); for (Field field : entity.getDeclaredFields()) { TableField tf field.getAnnotation(TableField.class); // TableField(exist false) 的字段不是表字段跳过 if (tf ! null !tf.exist()) { continue; } String column camelToUnderline(field.getName()); String type TYPE_MAP.get(field.getType()); ddl.append( ).append(column).append( ).append(type).append(,\n); } return ddl.append() ENGINEInnoDB DEFAULT CHARSETutf8mb4;).toString(); } private static String camelToUnderline(String name) { return name.replaceAll(([a-z])([A-Z]), $1_$2).toLowerCase(); } }这段代码的逻辑分三步通过 TableName 拿到表名遍历实体类的所有字段用 TableField 注解判断字段是否映射到数据库列把 Java 类型映射成 MySQL 类型字段名从驼峰转下划线最后拼成 CREATE TABLE 语句。使用时有几个参数要注意TYPE_MAP 里的类型映射不是全量的BigDecimal、Boolean、Date 这些常见类型需要自己补字段长度统一写成 128 只是最小可行值实际要根据业务调整比如用户名字段 64 就够而存储 JSON 的字段要用 TEXT工具类适合生成新表不适合改旧表因为生成器不感知已有索引、注释、唯一约束。使用这个工具时写一个简单的 main 方法或单元测试扫描 entity 包下所有类逐个调用 generate 输出再把结果粘贴到增量 SQL 脚本里执行。这个方案虽然简陋但能保证「实体类改了SQL 跟着生成」比手写可靠。5.2 把初始化 SQL 和增量脚本纳入 git 基线很多项目的 SQL 脚本管理是一团乱麻初始化脚本和增量修改混在同一个文件里部署新环境时不知道执行哪些文件。我的习惯是把 SQL 分成两个目录sql/ 放初始化基线脚本sql/migrate/ 放增量脚本增量脚本命名按日期和功能来比如 V20240601_add_dept_unique.sql。所有业务表结构变更必须新增增量脚本绝不直接改初始化脚本这样新环境部署就是「先跑基线再按顺序执行所有 migrate 脚本」。检查增量有没有漏可以用命令对比当前库和基线结构# 导出当前库的表结构不含数据 mysqldump -uroot -p ruoyi --no-data --skip-comments /tmp/schema_current.sql # 和基线脚本对比差异 diff /tmp/schema_current.sql sql/初始化基线.sql | head -100mysqldump 的参数 --no-data 表示只要表结构不要数据--skip-comments 去掉注释让对比结果更干净diff 输出里出现的差异行就是增量脚本应该体现的变更。如果当前库比基线多了字段而 migrate 目录里找不到对应脚本说明有人没走增量流程这是 code review 时要拦下来的问题。5.3 文档结构化把官方文档和踩坑记录汇成内部知识库文档的事情不要靠记忆也不要把官方文档改成自己私有版。我的做法是把官方文档转成统一格式的 markdown存进团队内部 git 仓库的 docs 目录踩坑记录以「现象-原因-解决」的结构追加到对应的技术页面。转换工具用 pandoc 即可# 将官方 html 文档转为统一格式的 markdown pandoc -f html -t gfm -o docs/quickstart.md quickstart.html # 搜索历史踩坑记录 grep -rn 租户不存在 docs/pandoc 本身只负责格式转换真正有价值的是后续的维护动作每解决一个问题就把排查过程和结论写进 docs 对应页面每次升级版本就把官方变更日志摘录进升级对照表。这套知识库配合上面说的 SQL 基线管理才能做到「新环境能复现、旧问题能检索」。如果有人再拿「文档不全」来推销你直接把自己库里的排查记录甩给他就行。6. 进阶用「三层清单法」把二开效率提上来最后聊一个我长期使用的习惯把若依系二次开发的工作方式固定下来。很多开发者拿到源码后直接开写改到一半发现表结构没有预留字段、接口权限没配、页面菜单没挂上来回返工。我的做法是先建三层清单再动工第一层列出需要新增或修改的数据表第二层列出对应的接口路径和权限标识第三层列出前端页面路由和菜单挂载点。这三层清单按顺序对应若依的数据库、controller、前端视图三层结构缺一层都会在联调时显现出来。举例来说要做一个客户管理模块清单应该是这样的表是 business_customer接口是 /business/customer/page 加 RequiresPermissions(business:customer:query)前端页面放在 views/business/customer/index.vue菜单挂在系统管理的业务管理目录下。写代码之前把这张表填完整实际开发就是照单填肉改动率会大幅下降。写完代码后我有三个固定验证动作用来区分「能跑」和「能用」。第一步登录后台确认菜单能渲染这是前后端链路通的标志第二步用 Swagger 调用一个带权限注解的接口不带权限头访问应该返回 403这验证鉴权没有漏第三步在数据库里对唯一字段插入重复数据确认报错能被业务层捕获并提示而不是裸抛 500。这三个检查做完模块才算真正交付。最后是版本基线习惯。我会把下载的源码、SQL 脚本、文档固定成一个版本快照在 git 里打上基线 tag官方升级时只 diff 基线到新版本的差异评估迁移成本后再决定要不要升级。这样再也不需要任何人提供所谓的「最新整合包」因为升级路径完全掌握在自己手里。某位开发者当初花钱买了整合包后来发现就是官方源码加文档加 SQL 的合集他自己照着官方文档重新搭了一遍反而把整个部署链路彻底搞懂了从此再没人能拿「文档不全」拿捏他。这套方法希望帮到你。本文还有配套的精品资源点击获取
