ServiceLoader 是 Java 原生 SPI 加载器，不直接提供变量插件化能力，而是作为插件发现与装配的核心基础设施：严格遵循 META-INF/services 规范加载所有候选实现，再由业务代码结合上下文（如渠道、环境）动态筛选、排序和启用，实现运行时可配置、可切换、可扩展的插件化架构。
ServiceLoader 是 Java 原生的 SPI（Service Provider Interface）加载器，它本身不提供“变量插件化”能力，但能作为**插件发现与装配的核心基础设施**，支撑起真正可配置、可切换、可扩展的插件化架构。所谓“变量插件化”，本质是运行时根据上下文（如业务类型、渠道标识、环境配置等）动态选择并启用某个插件实现——而 ServiceLoader 负责把所有候选实现“列出来”，后续的筛选、排序、启用逻辑由你控制。
插件发现必须严格遵循 META-INF/services 规范
这是整个机制生效的前提，90% 的失败都卡在这一步：
- 文件路径必须是 src/main/resources/META-INF/services/接口全限定名（例如
com.example.PaymentProcessor），不能嵌套在子包下，也不能写成com/example/PaymentProcessor - 文件名不能带
.class后缀，大小写必须完全一致；内容每行一个实现类全限定名，末尾不能有空格、\r、BOM 或注释符号# - Maven 构建后，需解压 jar 确认该文件真实存在于根目录的
META-INF/services/下，且被 runtime classpath 加载到 - 多个插件模块时，确保它们的 jar 都在启动 classpath 中（Spring Boot 可检查
BOOT-INF/lib/；普通应用检查-cp参数）
用 ServiceLoader 做能力探查，不是直接执行
不要把 ServiceLoader.load(X.class) 返回的实例当成即用对象，它只是“可用候选列表”。变量插件化的关键，在于结合上下文做判断：
- 每个插件实现应提供
supports(PluginContext ctx)或getSupportTypes()方法，用于声明自己适配哪些业务场景（如channel == "wxpay"、tenant == "vip"） - 遍历所有加载到的实例，调用
supports()过滤出匹配项，再按getOrder()排序或按getVersion()选最新版 - 建议缓存已验证通过的实例（如
Map<String, Plugin>），避免重复判断；ServiceLoader 本身不缓存实例，只缓存配置元数据 - 示例：支付路由不写
if (channel.equals("alipay")) { new AliPayProcessor() }，而是loader.stream().filter(p -> p.supports(ctx)).findFirst()
生命周期与依赖需自主补足
ServiceLoader 用反射调无参构造器创建实例，不走 Spring 容器，因此@Autowired、@PostConstruct、AOP 等全部失效。变量插件化要求插件能随环境变化启停，这就需要你主动管理：
- 定义统一初始化接口，如
InitializingPlugin，含init(Config config)方法，在加载后统一传入配置并调用 - 避免在构造器中硬编码数据库连接、日志对象等，改用 setter 或 builder 模式注入外部依赖
- 对需释放资源的插件（如监听器、连接池），定义
DisposablePlugin接口，在应用关闭前批量调用destroy() - 若已有轻量 IoC（如 Guice 或自研容器），可在 ServiceLoader 加载后，将实例交由其托管，完成依赖注入和代理增强
分布式或微服务中不能跨进程使用
ServiceLoader 是 JVM 进程内机制，仅扫描本 classpath，无法加载远程服务、不支持服务发现、也不感知灰度/环境配置。所谓“变量插件化”在分布式场景下，必须分层设计：
- 协议层：定义统一插件接口（如
RateLimitPolicy），发布为独立 artifact - 部署层：各服务打包自己的实现（如
redis-rate-limiter），并通过配置中心（Nacos/Apollo）声明“本实例支持 Policy v1.2 + 灰度开关开启” - 运行时层：网关查配置中心确定路由目标 → 目标服务收到请求 → 再用
ServiceLoader.load(RateLimitPolicy.class)从本地加载执行 - 这样，SPI 仍负责“最后一公里”的实例加载，而变量决策（哪个环境用哪个插件）交给上层配置驱动
