Java SPI机制通过配置文件解耦接口与实现，支持插件式扩展；关键在META-INF/services的精准配置、避免与Spring冲突、多实现时需主动排序或配置驱动。
Java SPI（Service Provider Interface）机制本质是让接口和实现“不见面”，靠配置文件牵线搭桥，从而在不改核心代码的前提下替换或新增功能模块。它不是为了解决“怎么写类”，而是解决“怎么让类自己冒出来”。关键不在 ServiceLoader.load() 这一行代码，而在整个发现、加载、实例化的链条是否稳、可控、可维护。
插件变量架构的核心逻辑
所谓“插件变量”，指系统中那些行为不确定、来源可变、策略可配的功能点，比如日志输出格式、支付渠道选择、认证方式、规则引擎策略等。这些不是固定死的字段，而是运行时根据环境或配置动态决定的“变量式插件”。SPI 正适合承载这类需求：
- 定义统一接口（如 PaymentStrategy），所有具体实现（微信、支付宝、银联）都遵守这个契约
- 每个实现打包进独立模块，在 META-INF/services/com.example.PaymentStrategy 文件里写上实现类全名
- 主程序只依赖接口，通过 ServiceLoader.load(PaymentStrategy.class) 获取可用实现列表
- 业务层根据上下文（如用户地区、商户类型、配置开关）从中选取一个使用，而非硬编码 new AlipayService()
META-INF/services 配置必须精准
这是 SPI 失效最常见的断点。它不看路径深浅，只认 classpath 根下的固定位置：
- 文件路径必须是：src/main/resources/META-INF/services/com.example.PaymentStrategy（注意：是斜杠，不是点；包名用点分隔，但路径用斜杠）
- 文件名必须与接口全限定名完全一致，大小写敏感，不能带 .class 或其他后缀
- 文件内容每行一个实现类全限定名，例如：com.example.alipay.AlipayPaymentStrategy，末尾不能有空格或不可见字符（如 BOM）
- Maven 构建时确认该资源被复制进最终 jar 的根路径下——可解压 jar 检查 META-INF/services/ 是否存在且可读
避免 ServiceLoader 和 Spring 容器冲突
ServiceLoader 创建实例走的是纯反射（clazz.getDeclaredConstructor().newInstance()），它不管 Spring 的生命周期、依赖注入或 AOP。如果插件类里写了 @Autowired 字段，运行时一定为 null。
立即学习“Java免费学习笔记（深入）”；
- 若插件需 Spring 管理（如要事务、远程调用、配置注入），不要直接用 ServiceLoader 返回的对象
- 推荐做法：用 ServiceLoader 扫描出所有实现类名 → 再调用 applicationContext.getBean(implClass) 获取已托管 Bean
- 前提是这些实现类本身已被 Spring 扫描到（如加了 @Component），否则需手动注册或做轻量级依赖填充
多实现共存时的策略控制
SPI 不保证加载顺序，classpath 中 jar 排列由构建工具和启动方式决定，不可靠。需要明确策略时，别靠遍历顺序，而要靠设计：
- 每个实现类提供 int getOrder() 方法，业务层收集全部实例后按 order 排序，取第一个或过滤启用项
- 引入配置驱动：在 application.yml 中定义 payment.strategy=alipay，再通过名称匹配获取对应实现
- 支持运行时热插拔：监听 classpath 变化（如自定义 ClassLoader + WatchService），动态重载服务列表（适用于非生产调试场景）
