这个项目是什么
RuoYi Plus Market 是 RuoYi-Vue-Plus 的「平台 + 应用」形态。
它在保留 RuoYi-Vue-Plus 全部底座能力（多租户、Sa-Token 鉴权、MyBatis-Plus、OSS、任务调度、工作流……） 的前提下，把原本编译期耦合在宿主里的业务模块抽出来，做成可以后装、不重启、从应用市场拉下来直接跑的应用。
一句话概括改造目标：
平台只负责底座（用户 / 角色 / 菜单 / 租户 / 文件 / 调度），业务能力以「应用」为单位独立交付与升级。
它解决了什么问题
原版 RuoYi-Vue-Plus 是单体结构：所有业务模块都在同一个 reactor 里编译、打进同一个 jar。 这在"一套系统服务一个客户"时没问题，但一旦遇到下面的场景就会很痛：
| 场景 | 单体结构的痛点 |
|---|---|
| 同一套系统交付给 N 个客户 | 每个客户要的功能不同 → 要么带上全部模块，要么给每个客户维护一个分支 |
| 客户临时要加一个模块 | 改代码 → 重新编译 → 停机发版 |
| 某个模块升级 | 整个服务重启，影响其它所有模块 |
| 想开放第三方生态 | 没有技术隔离手段，第三方代码只能直接进主仓库 |
| 同一份目录要服务多套部署 | 上架一次要同步 N 遍 |
RuoYi Plus Market 的答案是应用化：
- 业务的契约（实体 / Mapper 接口 / Service 接口 / Mapper XML）留在平台 reactor 里的
ruoyi-<name>-api模块； - 业务的实现（controller / service.impl / listener）搬到
plugins/ruoyi-<name>，不进任何<modules>，独立构建； - 宿主只在编译期依赖契约，运行期通过服务定位器反查插件里的实现；
- 应用以签名的安装包形式在应用市场里分发，安装、升级、卸载全程热插拔，不需要重启。
和原版 RuoYi-Vue-Plus 的关系
| 维度 | 原版 RuoYi-Vue-Plus | 本项目 |
|---|---|---|
| 业务模块位置 | 编译期在宿主 reactor 里 | 独立插件工程，不在任何 <modules> 里 |
| 交付方式 | 发版一个 jar | 应用包（app.json + jar + 前端产物 + 迁移脚本） |
| 加载时机 | 启动期，写死在 classpath | 运行期，每插件独立类加载器 + 子上下文 |
| 业务升级 | 重启服务 | 热加载，无需重启 |
| 菜单与权限 | 初始化 SQL 手写 INSERT INTO sys_menu | 应用清单声明 → AppMenuPlanner 幂等 upsert |
| 数据表结构变更 | 手工执行 SQL / 平台初始化 SQL | 随应用包走的 migrations/*.sql，安装升级时自动执行 |
| 前端页面 | 在 plus-ui/src/views 里，随宿主一起构建 | 独立 ESM 远程产物，运行期按菜单加载 |
| 多客户交付 | 分支 / 手工裁剪 | 同一份平台代码 + 不同应用组合 |
| 包安全 | — | 产物白名单 + 分离式签名校验 |
底座能力（多租户、鉴权、代码生成、工作流、监控等）完全保留，这部分仍以上游 RuoYi-Vue-Plus 为准。
这个项目里有什么
当前仓库工作区内包含 10 个应用（数据来自各应用的 app.json 清单，可用 npm run gen:apps 重新生成）：
| 应用 | 编码 | 版本 | 形态 | 一句话 |
|---|---|---|---|---|
| 图床管理 | gallery | 1.0.5 | 前后端一体 | 多租户图床与相册 |
| 商城管理 | mall | — | 前后端一体 | 商品、订单、售后、营销 |
| 会员管理 | member | — | 前后端一体 | 会员等级、积分、余额 |
| 即时通讯 | im | — | 前后端一体 | 会话与消息 |
| 社交互动 | social | — | 前后端一体 | 动态、关注、互动 |
| 考试系统 | exam | — | 前后端一体 | 题库、试卷、考试 |
| 支付管理 | pay | — | 前后端一体 | 支付渠道、支付单 |
| 报价管理 | quote | — | 前后端一体 | 报价单 |
| 企业数据 | enterprise | — | 前后端一体 | 企业库 |
| 财务管理 | finance | — | 纯前端 | 聚合订单 / 售后 / 余额流水的报表页 |
完整清单与每个应用的能力见 应用生态。
什么情况下不要用这个项目
诚实地讲，这套改造付出了复杂度，只有下面这些情况才值得：
- 你确实需要一套代码服务多个客户，且客户之间功能组合不同；
- 你需要不停机地给线上环境加功能或升级某个模块；
- 你打算做应用市场 / 插件生态，需要第三方能上架应用；
- 你想把「平台」和「业务」的边界在工程结构上固化下来，而不是靠约定。
如果你的场景是"一套系统服务一个客户、功能固定"，那么直接用上游 RuoYi-Vue-Plus 更省事 —— 插件化带来的类加载器隔离、上下文管理、包签名这些机制，对你是纯粹的额外成本。