开始使用
为什么是无界创镜
大多数后台框架把「业务模块」编译在宿主里：加一个商城要改菜单、改路由、改权限、重新打包，升级时整站一起停。无界创镜把这件事反过来做：平台足够小，业务足够独立。
三个核心判断
平台只做底座
用户、角色、部门、菜单、租户、字典、参数、日志、文件存储，这些是所有业务都绕不开的能力，留在宿主。商城、会员、支付、考试、社交、图床、报价、企业库，这些是「可以选装」的能力，做成应用。
判断标准只有一句：这段代码是不是每个部署都必须有？ 不是，就应该是应用。
应用是完整交付物，不是一个 Java 模块
一个应用包同时包含：
- 后端 jar：独立的类加载器、独立的 Spring 子上下文、独立的 Mapper；
- 前端 ESM：后台按
appCode远程加载，不需要把业务页面编进宿主； - 数据库迁移：建表、字典、站点配置随包执行；
- 菜单清单：
app.json声明，安装时幂等写入，卸载时可回收。
所以「安装一个应用」等于交付一整套垂直功能，而不是让客户自己拼依赖。
生命周期不重启
安装、升级、停用、启用、卸载都在运行期完成：
- 落位产物（jar + 前端目录 + migrations）；
- 执行迁移脚本；
- 卸载旧插件（关闭子上下文、注销路由与 Mapper）；
- 加载新插件（新建类加载器与子上下文）；
- 同步菜单并刷新前端路由。
这条链路是平台最重要的不变量，也是插件运行时存在的原因。
和传统 RuoYi 项目的区别
| 维度 | 传统单体后台 | 无界创镜 |
|---|---|---|
| 新业务上线 | 改宿主、重新打包、重启 | 装应用，热加载 |
| 业务之间 | 直接依赖、共享 Service | 通过平台 SPI 或事件解耦 |
| 菜单 | 手写 SQL / 页面配置 | app.json 声明，安装时同步 |
| 数据库 | 全部混在平台库 | 迁移脚本随应用走，卸载可删 |
| 前端 | 所有页面编进一个工程 | 后台宿主 + 远程 ESM |
| 交付 | 整个仓库 | 应用包（可签名、可校验） |
| 多租户 | 业务表自行处理 | 平台统一租户上下文 |
代价与边界
这套架构不是没有成本，选择它之前需要接受：
- 调试链路更长：一个问题可能出在宿主、插件类加载器、子上下文、前端远程产物四层。
- 依赖必须显式：应用之间是运行期硬依赖，装错顺序会启动失败；必须在清单里声明。
- 安全边界更重：插件是任意 Java 代码，包签名与上传校验不是可选项。
- 不适合超小项目：只有一个业务、永远不扩展的系统，用单体更省事。
什么时候适合用
- 需要按客户选装功能的 SaaS 或私有化交付；
- 业务模块多、迭代节奏不同，希望独立发布；
- 有二次开发需求，但不希望每个客户都维护一个 fork；
- 能接受「平台 + 应用」的运维模型，并愿意为签名、迁移、监控投入。
如果只是做一个内部管理系统，且业务不会拆分，直接使用 RuoYi-Vue-Plus 会更轻。