ServiceLoader实现轻量级插件变量化开发的核心是配置驱动的实现切换，即通过稳定接口契约、可替换实现及META-INF/services配置文件控制启用不同插件，而非动态行为注入。
ServiceLoader 实现轻量级插件变量化开发，核心在于“接口契约稳定、实现可替换、配置即开关”。它不追求运行时热加载或复杂生命周期管理，而是通过编译期确定 + 资源驱动的方式，让不同环境、不同客户、不同业务场景能启用各自适配的插件实现——本质是**配置驱动的实现切换**，不是动态行为注入。
接口与实现的规范约束
这是整个机制稳定运行的前提：
- 服务接口必须是 public 的，并且在模块系统（如 module-info.java）中明确
exports，否则 ServiceLoader 找不到类定义 - 所有实现类必须提供 public 无参构造函数；有参构造或私有构造会导致实例化失败且静默跳过（
hasNext()返回 false） - 避免在实现类的
static块中执行 I/O、网络、数据库连接等重操作——SPI 初始化阶段会阻塞，且失败不可恢复 - 接口方法应尽量保持幂等、无状态；若需上下文，建议通过方法参数传入，而非依赖外部 Spring Bean 或静态单例
META-INF/services 配置规范
这是插件是否被识别的唯一入口，容错率极低，必须严格遵循：
- 文件路径必须为
META-INF/services/接口全限定名（例如com.example.auth.AuthProvider），不能带.class后缀，大小写、点号、斜杠一个都不能错 - 文件必须放在 classpath 根路径下（即 src/main/resources 目录直接生成的 META-INF/services/…），不是
resources/com/example/...这类子路径 - 每行一个实现类全限定名，末尾不能有空格、BOM 字符或不可见 Unicode 符号；
#开头行为注释，会被忽略 - 多个实现共存时，按 classpath 中 jar 的加载顺序遍历，但该顺序不保证跨环境一致，因此不得依赖加载顺序做逻辑分支
变量化使用的工程实践
所谓“变量化”，是指同一套主程序，通过更换插件实现或配置，适配不同变量（如客户、渠道、地区、合规要求）。推荐做法：
- 每个插件实现类可自带标识字段（如
String vendor()、int priority()），运行时收集全部实现后按需筛选或排序 - 用外部配置（如 application.yml）控制启用哪个实现，例如：
auth.provider=wechat，再匹配实现类中的vendor()值 - 若需灰度或开关控制，不要删配置文件，而是在实现类中读取配置或检查环境变量，
log()方法内直接 return - 构建时通过 Maven Profile 或 Gradle Variant 分别打包不同客户版本：每个版本只包含对应客户的插件 jar 和其配置文件，确保 classpath 干净、意图明确
与 Spring 等容器协同的关键提醒
ServiceLoader 本身不参与 Spring 生命周期，这点必须清醒认识：
- ServiceLoader 返回的对象不是 Spring Bean，
@Autowired字段为 null，@PostConstruct不触发，AOP 代理失效 - 若插件需依赖 Spring 容器能力，应将 ServiceLoader 仅用于“发现”——获取实现类名 → 再调用
applicationContext.getBean(implClass)获取托管实例 - 更稳妥的做法是：插件实现类本身加
@Component，同时保留 SPI 配置，形成“双注册”，兼顾 SPI 发现和 Spring 管理
