业内人士表示，你把一个 Java 服务打成了单个 fatjar 发布出去。然后现实来了：运维想把数据源指向另一台主机，却不想让你重新构建；业务团队想在凌晨两点把某个模块下线，又不想重启整个进程。如果你唯一的答案是"重新打包、整包重发"，那每一次都能感觉到那股摩擦。 科技新闻。
一个好用的心智模型：E-Spi 把 文件 挪到 jar 外面，H-Spi 把 模块 搬进各自的运行时气泡里。一个关乎部署便利，一个关乎运维隔离。不少团队两个都用 —— E-Spi 管外置配置，H-Spi 管那一两个真正需要热替换的模块。
底层其实就是 AppClassLoader.addJar(URL | File)。这一个细节就解释了 E-Spi 的全部性格：
Sp背景与起因
一个可热插拔的插件实现 Plugin 接口。start 里注册模块需要的东西；stop 里必须移除它注册过的每一个资源，否则卸载时就会泄漏：
E-Spi（体外扩展）直接瞄准 fatjar 部署这个场景。你指定一个扩展目录，启动时 Solon 扫描它并加载发现的内容：
Solon 恰好为这道缝隙准备了两套机制：E-Spi（体外扩展）和 H-Spi（热插拔）。它们落在同一条谱系的不同位置上，选错了，代价要么是灵活性、要么是稳定性。下面讲清楚各自怎么用、什么时候用哪个。
Sp事件经过
隔离就是这套机制的全部意义，所以类的可见性规则很关键：
fatjar 部署起来方便，改起来难受。配置文件、业务模块，全都烤进了包里。E-Spi 和 H-Spi 都能撬开这层密封，但契约截然不同：
给值加上 ! 前缀，Solon 会帮你把目录建出来：
Sp各方回应
一个打包上的提醒：插件 jar 要么自身打成 fatjar，要么把依赖折进主应用（尤其是公共依赖应放在主应用的构建里，插件自己的 pom 把它们标为 optional）。
从这个问题开始想："这东西必须在不重启的情况下变更吗？"
模板渲染还有一个 ClassLoader 上的坑 —— 渲染器必须钉在正确的 ClassLoader 上：
Sp影响分析
如果你正在为一个要长期演进的 Solon 服务做结构设计，值得把两篇官方文档从头到尾读一遍再定 —— 尤其是 ClassLoader 那套规则，认真读第一遍很值。
H-Spi（热插拔）是更重的工具。你把一个业务模块开发成自包含的插件包，运行中的服务可以实时加载和卸载它。与 E-Spi 最本质的区别是隔离：
跨模块通讯，靠事件总线配弱类型载荷（Map / JSON 字符串）；DamiBus 在这里做解耦很搭。官方示例包：demo1011。插件管理还可以借助 solon-hotplug 进一步推向仓库或平台。
官方示例：demo2002-external_ext（在 solon-examples 仓库的 2.Solon_Advanced 下）。
现在数据源配置落在 jar 外的 _db.properties 里，两个业务模块作为独立的插件 jar 一起随行。运维可以直接改那个 properties 文件，你完全不用碰 fatjar。
那个 stop 方法就是热插拔要交的税。路由、任务、事件订阅、静态仓库 —— start 加了什么，stop 就得移除什么。漏一行，卸载后就留下幽灵路由或泄漏的监听器。
如果你更愿意在代码里加载这些额外内容，内核直接暴露了接口：
你的 fatjar 最需要先甩掉的是什么：配置，还是整个模块？，成为近期热点话题。
