1. 为什么要在 RuoYi 分离版里用 IDEA 做子模块开发？这事儿真不是“点几下就完事”
RuoYi 分离版——这个在 Java 后端圈子里被无数中小团队反复验证过的快速开发脚手架，它的核心价值从来不是“多炫酷”，而是“少踩坑、快上线、易维护”。但凡你真正带过一个 3–5 人的后端小队，就会明白：当业务开始分域（比如把“客户管理”从系统主模块里拆出来独立迭代）、当新同事入职要快速上手某个功能模块、当运维要求按模块粒度做灰度发布或资源隔离时，“子模块”就不再是教科书里的概念，而是每天要面对的现实压力。而 RuoYi 分离版的 Maven 多模块结构，恰恰为这种演进提供了天然骨架。但问题来了：官方文档里写的“手动建 module → 改 pom → 拷包结构 → 配 controller/service/mapper → 补 yml → 加菜单 → 刷缓存”，一套流程走下来，光是复制粘贴模板代码就得花掉 40 分钟，还极易漏掉 mapper.xml 的 namespace、漏配 MyBatis 的 typeAliasesPackage、或者忘记在 ruoyi-admin 的 Spring Boot Starter 里声明新模块的自动配置类——这些细节一旦出错，轻则启动报错，重则线上菜单不显示、接口 404，排查起来全是“我以为它该有”的隐性依赖。
这时候，RuoYi 自带的代码生成器（CodeGenerator）就不是锦上添花了，而是救命稻草。它能把“建表 → 设计字段 → 生成实体/DAO/Service/Controller/前端页面”这一整条链路压缩到 5 分钟内完成，而且生成的代码风格、包路径、注解规范、事务边界、日志埋点全部和主项目保持一致。但关键难点在于：分离版的代码生成器默认只面向 ruoyi-system 这个核心模块，它压根不知道你要往 ruoyi-customer 或 ruoyi-order 这类自定义子模块里塞代码。IDEA 作为主力开发工具，其 Maven 集成、模块依赖图谱、实时编译反馈、断点调试能力，是 Eclipse 或 VS Code 在复杂多模块项目中难以替代的。所以，“RuoYi(分离版) 使用代码生成器添加子模块(idea版)”这件事的本质，不是教你怎么点菜单，而是帮你打通一条从数据库表设计到可部署服务的全自动流水线——让子模块不再是“手工缝合”的补丁，而是能像原生模块一样被 IDE 识别、被 Maven 管理、被 Spring Boot 扫描、被前端路由动态加载的“一级公民”。我去年在给一家做区域医疗 SaaS 的客户做二次开发时，就是靠这套流程，在两周内交付了包含 7 个独立子模块（患者档案、检验报告、药品库存、医嘱执行等）的定制化版本，每个模块都支持独立打包、独立配置、独立监控。如果你还在用复制粘贴的方式维护子模块，那不是你在写代码，是在给技术债做定期存款。
2. 整体设计思路：绕开“改源码”的坑，用配置驱动生成逻辑
很多人第一次尝试给 RuoYi 分离版加子模块，第一反应是去翻 ruoyi-generator 模块的源码，想直接修改 GeneratorConfig.java 或者 TemplateServiceImpl.java，把 targetProject 路径硬编码成自己的子模块名。这路子看似直接，实则埋雷无数：一是每次 RuoYi 升级，你都得重新 merge 这些改动，冲突概率极高；二是生成器本身是 Web 页面操作，所有配置都存在数据库里，硬改 Java 代码会导致前后端配置不一致；三是不同子模块可能需要不同的包名前缀、不同的 Swagger 分组、不同的权限控制粒度，全靠改代码根本无法灵活适配。我们真正要做的，是把子模块的元信息（模块名、包路径、作者、数据库表前缀）变成可配置项，让生成器在运行时动态解析，而不是在编译时静态写死。
整个方案的核心设计原则就三条：
第一，零侵入主工程。所有改动都集中在 ruoyi-generator 模块内部，不碰 ruoyi-admin、ruoyi-system、ruoyi-framework 这些核心模块的一行代码。这意味着你可以随时拉取官方最新 release 版本，只需把 generator 模块替换成你的增强版即可。
第二，配置即契约。新增一个子模块，只需要在 ruoyi-generator 的数据库表 sys_gen_table 中插入一条记录，指定 module_name（如 customer）、package_name（如 com.ruoyi.customer）、author（如 team-medical），生成器就能自动推导出目标路径、包结构、Swagger 分组名。不需要改任何 Java 类，也不需要重启服务。
第三，IDEA 是调度中心，不是执行终端。很多人误以为“IDEA 版”就是指在 IDEA 里点右键生成，其实恰恰相反——IDEA 在这里扮演的是“配置下发器”和“结果验证器”。真正的代码生成逻辑依然在 ruoyi-generator 的 Spring Boot Web 应用里执行，IDEA 只负责：① 通过 Maven 插件调用 generator 的 REST API；② 将本地子模块的 pom.xml 和 src/main/resources/application.yml 路径同步给 generator；③ 在生成完成后，自动刷新 IDEA 的 Maven 项目视图，确保新模块被正确识别。这样既保证了生成逻辑的集中管控，又充分利用了 IDEA 的工程管理能力。
这个设计带来的直接好处是：当你需要为销售部门快速搭建一个“线索管理”子模块时，只需在后台生成器页面填一张表单（模块名：lead，包名：com.ruoyi.lead，表前缀：sys_lead_），点击生成，30 秒后 IDEA 里就出现一个完整的、可立即 run 的新模块，连单元测试类和 Swagger 文档都已就位。而这一切，都不需要你打开任何一个 Java 文件去手动改 import 语句。
3. 核心细节解析：从数据库配置到 IDEA 工程识别的全链路打通
3.1 数据库层：扩展 sys_gen_table 表，注入子模块元数据
RuoYi 的代码生成器所有配置都持久化在 sys_gen_table 表中，原始字段包括 table_name、table_comment、class_name、tpl_category 等。要支持子模块，必须在这张表里增加三个关键字段：
module_name：VARCHAR(64)，非空，存储子模块的 Maven artifactId，例如ruoyi-customer。这个值将决定生成代码的目标 module 目录。package_name：VARCHAR(128)，非空，存储该模块的 Java 包根路径，例如com.ruoyi.customer。它将覆盖 generator 默认的com.ruoyi.system。is_sub_module：CHAR(1)，默认 'N'，当值为 'Y' 时，表示此表生成的代码应放入指定子模块，而非默认的 ruoyi-system。
提示：修改表结构前，请务必备份数据库。执行 SQL 如下（以 MySQL 为例）：
ALTER TABLE sys_gen_table ADD COLUMN module_name VARCHAR(64) DEFAULT '' COMMENT '子模块名称', ADD COLUMN package_name VARCHAR(128) DEFAULT '' COMMENT 'Java 包路径', ADD COLUMN is_sub_module CHAR(1) DEFAULT 'N' COMMENT '是否为子模块（Y/N）';
这三个字段不是孤立存在的。它们共同构成了一套“生成契约”：当is_sub_module = 'Y'时，generator 会忽略所有硬编码的路径，转而根据module_name查找本地 workspace 中对应模块的物理路径，并用package_name替换模板中的默认包名。例如，你配置module_name=ruoyi-customer，generator 就会去扫描 IDEA 工程根目录下的ruoyi-customer文件夹是否存在；如果存在，就将生成的 Java 文件写入ruoyi-customer/src/main/java/com/ruoyi/customer/...，Mapper XML 写入ruoyi-customer/src/main/resources/mapper/customer/...，前端 Vue 文件写入ruoyi-ui/src/views/customer/...。这个查找逻辑不是凭空写的，而是基于 Maven 的标准 project structure 规范——只要你的子模块 pom.xml 里<artifactId>ruoyi-customer</artifactId>和module_name完全一致，generator 就能精准定位。
3.2 生成器后端：重构 TemplateServiceImpl，实现动态路径解析
ruoyi-generator 模块中的TemplateServiceImpl是生成逻辑的核心。原始版本中，getTargetPath()方法直接返回projectPath + "/ruoyi-system/src/main/java"这样的固定字符串。我们需要把它改成可插拔的策略模式。具体改造点有三处：
第一，在getTargetPath()方法中加入判断分支：
if ("Y".equals(table.getIsSubModule())) { // 动态查找子模块路径 String subModulePath = findSubModulePath(table.getModuleName()); if (StringUtils.isNotBlank(subModulePath)) { return subModulePath + "/src/main/java"; } else { throw new ServiceException("未找到子模块 [" + table.getModuleName() + "] 的工程路径，请检查模块名是否与 pom.xml 中的 artifactId 一致"); } } else { // 保持原有逻辑，生成到 ruoyi-system return projectPath + "/ruoyi-system/src/main/java"; }第二，实现findSubModulePath(String moduleName)方法。这个方法不能简单地new File(projectPath + "/" + moduleName)，因为实际项目中，子模块可能嵌套在ruoyi-all/ruoyi-customer这样的多层目录下。正确做法是递归扫描projectPath下所有pom.xml文件，解析其中的<artifactId>，与传入的moduleName匹配。我们用 SAX 解析器（避免引入大体积 DOM 解析库）逐行读取 pom.xml，一旦匹配成功，立即返回该 pom.xml 所在目录的绝对路径。实测下来，扫描一个含 20 个模块的工程，耗时不到 150ms，完全不影响生成体验。
第三，修改模板引擎的变量注入。原始模板中，packageName是写死的com.ruoyi.system。现在要改为从table.getPackageName()动态获取。在VelocityUtil.java的prepareContext()方法中，将context.put("packageName", table.getPackageName());替换为context.put("packageName", StringUtils.defaultString(table.getPackageName(), "com.ruoyi.system"));。这样即使你忘了填package_name，也会降级使用默认值，保证向后兼容。
注意：所有这些 Java 层的改动，都必须配合 ruoyi-generator 的
application.yml做一项关键配置——gen.project-path必须指向你 IDEA 工程的根目录绝对路径，而不是相对路径。例如，我的工程在D:\workspace\ruoyi-vue-pro，那么配置必须是gen: project-path: D:/workspace/ruoyi-vue-pro（Windows 下用正斜杠更稳妥）。这个路径是 generator 定位子模块的唯一坐标系原点，填错会导致“找不到模块”错误，且错误提示非常隐蔽（只会说“生成失败”，不会告诉你路径不对）。
3.3 IDEA 层：配置 Maven Profiles 与 Live Templates，让操作一键触达
IDEA 本身不提供“调用 Web 接口生成代码”的菜单，但我们可以通过 Maven 的 Profiles 机制，把 generator 的 REST API 调用封装成一条命令。在 ruoyi-generator 的 pom.xml 中，添加如下 profile：
<profile> <id>gen-sub-module</id> <build> <plugins> <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>exec-maven-plugin</artifactId> <version>3.1.0</version> <configuration> <mainClass>com.ruoyi.generator.util.GenApiCaller</mainClass> <arguments> <argument>${gen.tableName}</argument> <argument>${gen.moduleName}</argument> <argument>${gen.packageName}</argument> </arguments> </configuration> </plugin> </plugins> </build> </profile>然后创建一个GenApiCaller.java类，它不做任何业务逻辑，只是用OkHttpClient向http://localhost:8080/gen/table/generate发送 POST 请求，携带tableName、moduleName、packageName三个参数。这样，在 IDEA 的 Maven 工具窗口里，右键点击 ruoyi-generator → Profiles → gen-sub-module，再在 Run Configurations 里设置三个Properties（如-Dgen.tableName=sys_user -Dgen.moduleName=ruoyi-customer -Dgen.packageName=com.ruoyi.customer），点击运行，就能触发远程生成。
但更优雅的方式是结合 IDEA 的Live Templates。新建一个模板，缩写设为genmod，模板文本为：
mvn -Pgen-sub-module -Dgen.tableName="$TABLE$" -Dgen.moduleName="$MODULE$" -Dgen.packageName="$PACKAGE$" clean compile然后设置三个变量：TABLE绑定到groovyScript("def result=''; def selection = _editor.getSelectionModel().getSelectedText(); if(selection != null && !selection.isEmpty()) { result = selection }; result")，这样你选中数据库表名（如sys_user）后按快捷键，就能自动生成带参数的命令。我习惯把快捷键设为Ctrl+Alt+G，左手按住 Ctrl+Alt，右手敲 G，1 秒完成参数填充——这才是工程师该有的效率。
4. 实操过程：从零开始，5 分钟落地一个“设备管理”子模块
4.1 准备工作：创建子模块工程结构
打开 IDEA，确保你的 RuoYi 分离版工程已完整导入（File → Open → 选择 ruoyi-vue-pro 根目录）。在 Project 视图中，右键点击根目录 → New → Module。选择 Maven，GroupID 填com.ruoyi，ArtifactId 填ruoyi-device，Version 用4.8.0（与主工程一致），勾选 “Add as module to project”，点击 Finish。IDEA 会自动生成ruoyi-device目录及基础 pom.xml。此时，你需要手动编辑这个 pom.xml，加入关键依赖：
<dependencies> <!-- 继承 ruoyi-framework 的基础能力 --> <dependency> <groupId>com.ruoyi</groupId> <artifactId>ruoyi-framework</artifactId> <version>4.8.0</version> </dependency> <!-- 依赖 ruoyi-system 的通用 service，如 SysUserServiceImpl --> <dependency> <groupId>com.ruoyi</groupId> <artifactId>ruoyi-system</artifactId> <version>4.8.0</version> </dependency> <!-- 如果需要操作数据库，必须声明 mybatis-plus-boot-starter --> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3.1</version> </dependency> </dependencies>特别注意：<parent>标签必须指向根 pom.xml，即<parent><groupId>com.ruoyi</groupId><artifactId>ruoyi-vue-pro</artifactId><version>4.8.0</version></parent>。这是 Maven 多模块识别父子关系的基石。做完这一步，右键点击ruoyi-device→ Maven → Reload project，IDEA 应该能正确解析所有依赖，且ruoyi-device模块出现在 Project Structure → Modules 列表中。
4.2 数据库建表与生成器配置
在你的 MySQL 中，执行建表 SQL：
CREATE TABLE `sys_device` ( `device_id` bigint NOT NULL AUTO_INCREMENT COMMENT '设备ID', `device_code` varchar(64) NOT NULL COMMENT '设备编码', `device_name` varchar(128) NOT NULL COMMENT '设备名称', `status` char(1) DEFAULT '0' COMMENT '状态（0正常 1停用）', `create_by` varchar(64) DEFAULT '' COMMENT '创建者', `create_time` datetime DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', `update_by` varchar(64) DEFAULT '' COMMENT '更新者', `update_time` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间', PRIMARY KEY (`device_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='设备信息表';然后，登录 RuoYi 后台（http://localhost:8080），进入【系统工具】→【代码生成】→【生成代码】。点击右上角【新增】按钮，在弹窗中填写：
- 表名称：
sys_device - 表描述：
设备信息表 - 作者：
team-devops - 生成模板：
crud（默认） - 模块名称：
ruoyi-device（必须与你刚创建的 module artifactId 完全一致） - Java 包路径：
com.ruoyi.device - 是否为子模块：勾选 ✅
其他字段保持默认。点击【提交】，系统会跳转到列表页，新记录显示为“未生成”。此时，不要急着点【生成】，先确认一件事：打开 ruoyi-generator 的 application.yml，检查gen.project-path是否指向你的工程根目录（如D:/workspace/ruoyi-vue-pro）。如果路径不对，生成的文件会跑到 C 盘根目录下，导致 IDEA 完全看不到。
4.3 执行生成与工程整合
回到代码生成列表页，找到sys_device这一行，点击【生成】按钮。后端会开始执行：扫描ruoyi-device模块路径 → 创建com.ruoyi.device.domain.Device实体类 → 生成DeviceMapper.java和DeviceMapper.xml→ 编写DeviceService和DeviceController→ 在ruoyi-ui/src/views/device/下生成 Vue 页面。整个过程约 8–12 秒，页面会提示“生成成功”。
生成完成后，最关键的一步来了：在 IDEA 中，右键点击ruoyi-device模块 → Maven → Reload project。这一步强制 IDEA 重新扫描src/main/java和src/main/resources下的新文件。你会发现，ruoyi-device下自动出现了完整的domain、mapper、service、controller包结构，且所有类都有正确的 import 语句和 Lombok 注解。此时，你可以直接在DeviceController的@GetMapping("/list")方法上打个断点，右键 → Debug 'DeviceController'，IDEA 会启动一个仅包含ruoyi-device模块的精简 Spring Boot 上下文（前提是你的ruoyi-admin的pom.xml中已声明<module>ruoyi-device</module>），验证接口是否能正常返回 JSON 数据。
4.4 前端集成与菜单配置
后端代码已就位，前端还需两步。第一步，打开ruoyi-ui/src/router/index.js，找到const modules = import.meta.globEager('./modules/**/*.js')这行，确保./modules/device/index.js已被自动创建（生成器会生成它）。第二步，登录后台，进入【系统管理】→【菜单管理】，点击【新增】，填写：
- 菜单名称：
设备管理 - 父菜单：
系统管理（或你指定的父节点） - 路由地址：
/device/device - 组件路径：
device/device/index - 权限标识：
device:list（与DeviceController中@RequiresPermissions("device:list")保持一致）
保存后，清除浏览器缓存，重新登录，左侧菜单栏就会出现“设备管理”项。点击进入，看到的就是生成器为你创建的完整 CRUD 页面：搜索框、表格列（设备编码、设备名称、状态）、操作按钮（新增、修改、删除、导出）。整个流程，从建表到上线可用，严格控制在 5 分钟以内。我做过计时测试：熟练工况下，建表 30 秒，后台配置 40 秒，生成 & reload 15 秒，菜单配置 25 秒，总计 2分30秒。剩下的时间，是用来喝口水，或者 review 一下生成的代码质量。
5. 常见问题与排查技巧实录：那些让你抓耳挠腮的“灵异事件”
5.1 问题速查表：高频故障与一招解决法
| 现象 | 根本原因 | 解决方案 | 实操心得 |
|---|---|---|---|
| 生成后 IDEA 里看不到新文件 | ruoyi-device模块未被 IDEA 正确识别为 Maven module，或pom.xml中缺少<packaging>jar</packaging> | 右键ruoyi-device/pom.xml→ “Add as Maven project”；检查pom.xml第一行是否有<packaging>jar</packaging>，没有就加上 | 这是新手最高频问题，占所有咨询的 65%。根源在于 IDEA 导入时未勾选“Auto-import”，建议在 Settings → Build → Build Tools → Maven → Importing 中，勾选 “Import Maven projects automatically” |
启动 ruoyi-admin 报错ClassNotFoundException: com.ruoyi.device.controller.DeviceController | ruoyi-admin的pom.xml中未声明<module>ruoyi-device</module>，或ruoyi-device的pom.xml中<parent>指向错误 | 检查ruoyi-admin/pom.xml的<modules>列表；用mvn dependency:tree -f ruoyi-admin/pom.xml | findstr device命令验证依赖是否被正确引入 | 不要用 IDEA 的图形界面去“添加 module”，必须手动编辑pom.xml。图形界面添加的 module 只存在于 IDEA 的 .idea 文件里，Maven 构建时完全不可见 |
| 生成的 Controller 接口返回 404 | DeviceController类上的@RequestMapping("/device")与ruoyi-ui的路由path: '/device/device'不匹配，或ruoyi-admin的application.yml中未开启spring.mvc.pathmatch.matching-strategy: ant_path_matcher | 统一约定：Controller 的@RequestMapping用单层路径（如/device），前端路由path用双层（如/device/device），并在application.yml中添加spring: mvc: pathmatch: matching-strategy: ant_path_matcher | Spring Boot 2.6+ 默认使用 PathPatternParser，它不支持/**这种老式通配符。RuoYi 的前端路由大量使用**，必须切回 ant_path_matcher，否则所有动态路由都会 404 |
生成的 Mapper XML 执行 SQL 报错Invalid bound statement (not found) | DeviceMapper.xml的namespace写成了com.ruoyi.system.mapper.DeviceMapper，而非com.ruoyi.device.mapper.DeviceMapper | 检查生成的DeviceMapper.xml第一行：<mapper namespace="com.ruoyi.device.mapper.DeviceMapper">。如果错了，说明package_name配置有误，或TemplateServiceImpl中的packageName变量未正确注入 | 这个错误极其隐蔽，因为 Java 类编译通过，只有运行时才暴露。建议在ruoyi-device的src/test/java下写一个单元测试，用@Autowired DeviceMapper mapper; mapper.selectList(null);主动触发，比等接口调用时报错更快定位 |
5.2 独家避坑技巧：来自 37 次线上事故的血泪总结
技巧一：用“生成预览”代替盲目生成
RuoYi 的代码生成器有个隐藏功能：在填写完配置后，不要直接点【生成】，而是点【预览】。它会弹出一个模态框，列出所有将要生成的文件路径和内容摘要。重点看两点：①targetPath是否指向你的ruoyi-device目录；②packageName是否为com.ruoyi.device。如果这两项错了，立刻返回修改module_name和package_name，避免生成垃圾文件污染工程。我见过最惨的案例，是把module_name错填成ruoyi_device（下划线），导致生成器在根目录下创建了一个叫ruoyi_device的文件夹，里面塞满了代码，而真正的ruoyi-device模块却空空如也。
技巧二：子模块的application.yml必须独立配置 datasource
很多开发者以为子模块可以复用ruoyi-admin的数据源，于是在ruoyi-device/src/main/resources/application.yml中只写server: port: 8081，其他全删。这是大忌。ruoyi-device是一个独立的 Spring Boot Starter，它需要自己的spring.datasource配置才能初始化 MyBatis。正确做法是：复制ruoyi-admin/src/main/resources/application.yml中的spring: datasource:片段，粘贴到ruoyi-device/src/main/resources/application.yml中，并确保url、username、password与主库一致。否则，DeviceMapper的@Select方法会因找不到数据源而抛IllegalStateException。
技巧三：前端路由的name字段必须全局唯一
生成器为ruoyi-ui/src/views/device/device/index.vue自动生成的路由name: 'Device'。但如果项目里已有ruoyi-system的User组件，它的路由name也是'User'，就会导致 Vue Router 的name冲突，页面白屏。解决方案有两个：① 在生成器配置时，把“表描述”填成“设备管理”，生成器会自动把name设为'DeviceManage'；② 手动修改ruoyi-ui/src/router/modules/device/index.js中的name: 'DeviceManage'。记住，Vue Router 的name是内存级的唯一标识，比path更重要，绝不能重复。
技巧四：永远在ruoyi-admin的pom.xml中启用maven-compiler-plugin
默认的ruoyi-admin/pom.xml里，maven-compiler-plugin的<source>和<target>是 1.8。但如果你的ruoyi-device用了 Lombok 的@RequiredArgsConstructor(onConstructor = @__({@Autowired}))这种 Java 11+ 语法，编译就会失败。必须在ruoyi-admin/pom.xml的<build><plugins>里，显式声明：
<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <configuration> <source>11</source> <target>11</target> </configuration> </plugin>然后右键ruoyi-admin→ Maven → Reload project。这个配置会继承给所有子模块，确保编译一致性。
6. 进阶实战：如何让子模块支持多数据源与独立部署
当你把“设备管理”子模块跑通后，业务往往会提出更进一步的需求：“设备数据要单独放在一台数据库服务器上，不能和用户数据混在一起”，或者“这个模块要给合作伙伴单独部署，不希望他们看到我们的客户管理代码”。这就触及了 RuoYi 分离版的高阶能力——多数据源路由与子模块独立打包。
实现多数据源，核心在于ruoyi-device模块的DataSourceConfig.java。你需要在ruoyi-device/src/main/java/com/ruoyi/device/config/下新建这个类，用@Configuration和@Primary标记主数据源（指向设备库），再用@Bean(name = "deviceDataSource")声明第二个数据源。关键点在于：DeviceMapper的@MapperScan注解必须指定sqlSessionFactoryRef = "deviceSqlSessionFactory"，否则 MyBatis 会默认使用ruoyi-admin的主数据源。我推荐用dynamic-datasource-spring-boot-starter这个成熟组件，它通过@DS("device")注解就能切换数据源，比手写 AbstractRoutingDataSource 稳定得多。
至于独立打包，本质是让ruoyi-device模块具备spring-boot-maven-plugin的打包能力。在ruoyi-device/pom.xml中，加入：
<build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> <configuration> <mainClass>com.ruoyi.RuoYiApplication</mainClass> <includes> <include> <groupId>com.ruoyi</groupId> <artifactId>ruoyi-device</artifactId> </include> </includes> </configuration> </plugin> </plugins> </build>然后在ruoyi-device/src/main/java/com/ruoyi/device/DeviceApplication.java中，写一个极简的启动类：
@SpringBootApplication(exclude = {DataSourceAutoConfiguration.class}) @MapperScan("com.ruoyi.device.mapper") public class DeviceApplication { public static void main(String[] args) { SpringApplication.run(DeviceApplication.class, args); } }执行mvn clean package -f ruoyi-device/pom.xml，就会在ruoyi-device/target/下生成ruoyi-device-4.8.0.jar。这个 jar 包自带 Tomcat，双击即可运行，端口默认 8080，接口路径/device/list完全不变。合作伙伴拿到这个 jar，配上他们的application.yml，就能零依赖部署，连ruoyi-admin都不需要。
我在给一家智能硬件厂商做定制时，就是用这套方案，把“固件升级”、“设备告警”、“远程诊断”三个子模块分别打包成独立 jar，交给他们的运维团队。他们用 Ansible 脚本一键分发到 200+ 台边缘网关上，整个过程无需 Java 开发介入。这已经不是简单的代码生成了，而是把 RuoYi 从一个“单体框架”，变成了一个可插拔的“微服务组装平台”。而这一切的起点，就是你在 IDEA 里右键点击那个genmod模板，敲下的那几个字母。
