ServiceLoader + SPI 是 JVM 层最轻量、最标准的插件发现机制，适用于 CLI 工具、批处理引擎等无 Spring 容器场景；需严格遵循 META-INF/services/ 下接口全限定名配置文件规范，支持能力探查、排序筛选与生命周期自主管理，但仅限单机进程内生效。
ServiceLoader + SPI 是 JVM 层最轻量、最标准的插件发现机制，适合在不依赖 Spring 容器的场景下构建高扩展性业务插件架构——比如 CLI 工具、批处理引擎、规则编排中间件、嵌入式服务或基础框架内核。关键在于把“发现”和“执行”解耦，不强求容器托管，而是聚焦接口契约、资源规范与运行时策略。
严格遵循 SPI 资源规范是前提
所有插件行为都始于 classpath 根路径下的 META-INF/services/。这个环节出错，后续全失效：
- 文件必须放在 src/main/resources/META-INF/services/ 下（不是 resources/META-INF/services/com/example/… 的子目录）
- 文件名必须是接口的全限定名，例如
com.example.PaymentProcessor，不能带.class或大小写错误 - 文件内容每行一个实现类全限定名，如
com.alipay.AliPayProcessor，末尾不能有空格、BOM 或注释 - Maven 构建后，解压 jar 确认该文件真实存在且可读；多模块时，确保插件 jar 被显式引入 runtime classpath
用 ServiceLoader 做“能力清单”，而非直接执行
不要让业务逻辑直接调用 service.perform()。应将其视为一次“能力探查”，再结合上下文做决策：
- 遍历所有加载到的实现，调用其
getSupportTypes()或supports(PluginContext ctx)方法判断是否适用当前场景 - 对支持的实现按
getOrder()排序，或按getVersion()选最新稳定版 - 缓存已验证可用的实例（ServiceLoader 本身懒加载+缓存，但建议业务层再封装一层 Map
提升复用效率） - 示例：支付路由不写死 if-else，而是
loader.stream().filter(p -> p.supports(channel)).findFirst()
主动管理生命周期与依赖注入
ServiceLoader 实例化不走 Spring，所以需自行补足缺失能力：
- 若插件需访问数据库、配置或日志，定义统一初始化接口，如
InitializingPlugin，在加载后统一调用init(Config config) - 避免在插件构造器里硬编码依赖，改用 setter 或 builder 模式传入外部对象
- 对需要销毁资源的插件（如连接池、监听器），定义
DisposablePlugin并在应用退出前批量调用destroy() - 如已有轻量 IoC 容器（如 Google Guice 或自研 MiniContainer），可在加载后将实例交由其管理，完成字段注入
配合外部机制突破单机限制
SPI 本身是进程内机制，但可通过组合设计支持更复杂扩展需求：
- 插件元数据外置：每个插件 jar 包含
META-INF/plugin.yml，声明名称、版本、兼容范围、所需权限等，启动时统一扫描解析 - 灰度与环境隔离：通过系统属性或启动参数（如
-Dplugin.env=prod）过滤加载，ServiceLoader.load()后立即按 env 字段筛掉不匹配项 - 热插拔基础：监听
lib/目录变化，用自定义 ClassLoader 加载新增 jar，并重新触发 ServiceLoader 扫描（注意类卸载与内存泄漏风险） - 与配置中心联动：从 Nacos/Apollo 拉取“启用插件列表”，只加载白名单内的实现类，避免无用加载
