这个项目是什么
本文是 1.x 的归档文档（冻结于 1.x）。该分支只接收勘误修正， 内容基本不再变动；文中的源码路径、配置项与版本号均以 1.x 为准，不建议用于新项目。
新项目请查看 5.x 最新文档。已在 1.x 上运行的项目，本文仍是可靠依据。
Wujies 无界平台是一个「平台 + 应用」形态的后端平台：平台只负责底座 （用户 / 角色 / 菜单 / 租户 / 文件 / 调度），业务能力以「应用」为单位独立交付。
它源自 RuoYi-Vue-Plus，保留了它全部底座能力 （多租户、Sa-Token 鉴权、MyBatis-Plus、OSS、任务调度、工作流……）， 但把原本编译期耦合在宿主里的业务模块改成了可以后装、不重启、从应用市场拉下来直接跑的应用。 上游的具体用法（工作流、代码生成等底座功能）仍以上游文档为准。
一句话概括：
平台极小、应用外置、装完即用 —— 业务能力以「应用」为单位独立交付与升级。
它解决了什么问题
上游的工作方式是单体结构：所有业务模块在同一个 reactor 里编译、打进同一个 jar。 这在"一套系统服务一个客户"时没问题，但遇到下面这些场景会很痛：
| 场景 | 单体结构的痛点 |
|---|---|
| 同一套系统交付给 N 个客户 | 每个客户要的功能不同 → 要么带上全部模块，要么给每个客户维护一个分支 |
| 客户临时要加一个模块 | 改代码 → 重新编译 → 停机发版 |
| 某个模块升级 | 整个服务重启，影响其它所有模块 |
| 想开放第三方生态 | 没有技术隔离手段，第三方代码只能直接进主仓库 |
| 同一份应用目录要服务多套部署 | 上架一次要同步 N 遍 |
本项目的答案是应用化：
- 每个应用是自包含的一个工程：实体 / BO / VO / Mapper 接口 与 Mapper XML /
Service 接口与实现 / controller / listener / 定时任务 /
app.json/migrations/全在它自己目录下。平台对cn.wujies.<app>.*的 Java 引用为 0； - 应用在插件仓库里独立构建，新增业务模块不需要动平台一行；
- 应用以签名的安装包形式在应用市场里分发，安装 / 升级 / 卸载全程热插拔，不需要重启宿主；
- 应用之间要互相调用时，依赖兄弟应用的构件（编译期类型可见）， 运行期取 bean 走平台 SDK 的契约 + 定位器 —— 这两件事的区别见 跟着 hello 读源码。
本项目早期（2026-09-30 之前）的架构是「契约放在平台的 *-api 模块、实现放在 plugins/*」。
那个结构已经被整个推翻：现在平台里 wujies-modules/*-api 的数量是 0。
如果你在别的文档里看到"契约模块 *-api"，那是历史，见必须遵守的不变量。
和上游 RuoYi-Vue-Plus 的关系
| 维度 | 上游 | 本项目 |
|---|---|---|
| 业务模块位置 | 编译期在宿主 reactor 里 | 插件仓库里的独立工程，自包含 |
| 交付方式 | 发版一个 jar | 应用包（app.json + jar + 前端产物 + 迁移脚本） |
| 加载时机 | 启动期，写死在 classpath | 运行期，每应用独立类加载器 + 子上下文 |
| 业务升级 | 重启服务 | 热加载，无需重启 |
| 菜单与权限 | 初始化 SQL 手写 INSERT INTO sys_menu | 应用清单声明 → AppMenuPlanner 幂等 upsert |
| 数据表结构变更 | 手工执行 SQL | 随应用包走的 migrations/*.sql，安装升级时自动执行 |
| 前端页面 | 随宿主一起构建 | 独立 ESM 远程产物，运行期按菜单加载 |
| 多客户交付 | 分支 / 手工裁剪 | 同一份平台代码 + 不同应用组合 |
| 包安全 | — | 产物白名单 + 分离式签名校验 |
| 平台版本形态 | — | 同一份代码两种角色：官方版（有上架端）/ 用户版（只装不卖） |
底座能力（多租户、鉴权、OSS、任务调度、工作流、监控等）完全保留。
这个项目里有什么
应用清单、版本、菜单数这些不要手写在这里 —— 它们由
npm run gen:apps 扫描各应用的 app.json 生成，站点上的
应用生态 一页就是读这份数据渲染的。
要改应用的数量、版本、能力描述，改应用清单，不要改文档。
什么情况下不要用这个项目
诚实地讲，这套改造付出了复杂度，只有下面这些情况才值得：
- 你确实需要一套代码服务多个客户，且客户之间功能组合不同；
- 你需要不停机地给线上环境加功能或升级某个模块；
- 你打算做应用市场 / 插件生态，需要第三方能上架应用；
- 你想把「平台」和「业务」的边界在工程结构上固化下来，而不是靠约定。
如果你的场景是"一套系统服务一个客户、功能固定"，那么直接用上游 RuoYi-Vue-Plus 更省事 —— 插件化带来的类加载器隔离、上下文管理、包签名这些机制，对你是纯粹的额外成本。
同样地，如果只想给自己的项目加几个业务模块、并不打算分发， 那也不必套这套结构：应用化真正买到的是分发与隔离，不是"代码更整洁"。