关于
这个项目和上游 RuoYi-Vue-Plus 是什么关系，以及它能给你什么、不能给你什么。
和上游的关系
底座能力完全保留，业务交付方式被重做。
| 维度 | 原版 RuoYi-Vue-Plus | 本项目 |
|---|---|---|
| 业务模块位置 | 编译期在宿主 reactor 里 | 独立插件工程，不在任何 <modules> 里 |
| 交付方式 | 发版一个 jar | 应用包（清单 + jar + 前端产物 + 迁移脚本） |
| 加载时机 | 启动期，写死在 classpath | 运行期，每插件独立类加载器 + 子上下文 |
| 业务升级 | 重启服务 | 热加载 |
| 菜单与权限 | 初始化 SQL 写 INSERT INTO sys_menu | 应用清单声明 → 幂等 upsert，复用 menu_id |
| 表结构变更 | 手工执行 SQL | 随包走的 migrations/*.sql，安装升级时执行 |
| 前端页面 | 随宿主一起构建 | 独立 ESM 远程产物，运行期按菜单加载 |
| 多客户交付 | 分支 / 手工裁剪 | 同一份平台代码 + 不同应用组合 |
| 包安全 | — | 产物白名单 + 分离式签名校验 |
多租户、Sa-Token 鉴权、MyBatis-Plus、OSS、任务调度、工作流、代码生成、监控这些 底座能力以上游为准，本项目没有改动它们的语义。
什么情况下不要用它
诚实地讲，这套改造付出了复杂度。
适合
- 一套代码服务多个客户，且客户之间功能组合不同
- 需要不停机地给线上加功能或升级某个模块
- 要做应用市场 / 插件生态，让第三方能上架
- 想把「平台」和「业务」的边界在工程结构上固化下来
不适合
- 一套系统服务一个客户、功能固定
- 不需要后装 / 热升级 / 多形态交付
- 团队规模很小、维护不了类加载器与签名这套机制
这种情况直接用上游 RuoYi-Vue-Plus 更省事 —— 插件化对你是纯粹的额外成本。
当前状态
数字来自各应用的 app.json 清单。
| 应用数量 | 10 个（前后端一体 9 / 纯前端 1） |
| 菜单规模 | 496 条（页面 95 / 按钮权限 401） |
| 平台版本 | RuoYi-Vue-Plus 5.6.2 / Spring Boot 3.5.15 / JDK 17+ |
| 前端 | Vue 3.5 / Vite 6.3 / Element Plus |
| 已抽成应用的宿主模块 | quote / enterprise / member / pay / exam / im / social / mall（八个已完成） |
| 数据生成时间 | 2026-09-14 |
已知限制
这些是设计如此，不是 bug。
- 迁移只做 up，不回滚 —— 要回退表结构请自己写一个"反向"的新脚本。
- 已执行过的迁移脚本不能改 —— 摘要不一致直接拒绝执行，这是刻意的保护。
- 应用装的菜单不能改路由 / 权限字段，也不能删；想隐藏请用「停用」。
- 签名是单公钥模型 —— 与"开放第三方上架且什么都不改"目前是互斥的。
- 目录远程读取不做缓存 —— 避免"刚上架却装到旧版本"这类难解释的问题。
- 卸载默认不删数据 —— 「彻底删除」才删，且只删应用包声明过的表。
- 目录服务没有单独裁剪的产物 —— 同一个 jar 用配置切换角色。
许可与致谢
MIT 协议开源。
本项目基于 MIT 协议开源。底座能力来自 Dromara RuoYi-Vue-Plus， 感谢上游作者与社区；应用市场的插件运行时、远程应用与签名机制是在其之上的改造。
文档站与官网同仓库维护：官网是纯静态产物（本目录），
文档站是 VitePress 工程（website/docs/）。