serviceloader 不支持真正热插拔，仅支持重启或重新加载类路径资源；需确保 spi 配置合规、避免静态缓存实例、用业务策略排序替代加载顺序依赖，并与 spring 协同时通过容器获取 bean 而非直接使用 serviceloader 实例。
ServiceLoader 本身不支持真正的“热插拔”，它只支持启动时或运行中重新加载已变更的类路径资源，前提是类加载器能感知新版本、旧类已被卸载，且实现类无静态状态残留。所谓“变量动态热插拔”，本质是用 ServiceLoader 做服务发现，再配合外部控制（如配置开关、路由策略、实例缓存刷新）来切换当前生效的实现，而非 JVM 层实时替换字节码。
确保 SPI 配置完全合规
这是所有后续逻辑成立的前提。ServiceLoader 加载失败，99% 是因为这个环节出错：
- 文件必须放在 src/main/resources/META-INF/services/ 下，路径不能嵌套，也不能写成
META-INF/services/com/example/MyService - 文件名必须是接口的全限定名，例如
com.example.auth.AuthProvider，大小写、包名、点号一个都不能错 - 文件内容每行一个实现类全限定名，如
com.example.auth.JwtAuthProvider，末尾不能有空格、BOM、注释或空行 - Maven 打包后，解压 JAR 确认该文件真实存在于根目录
META-INF/services/中，且可被 ClassLoader.getResources() 找到
避免单例 ServiceLoader 导致“假热插拔”
ServiceLoader 实例内部持有一个懒加载的迭代器，且其缓存与 ClassLoader 绑定。若重复使用同一个实例，即使 classpath 已更新，它仍会返回旧类引用：
- 不要在 static 字段里缓存 ServiceLoader 实例
- 每次需要“刷新”可用实现时，应调用
ServiceLoader.load(MyService.class, classLoader)创建新实例 - 遍历前务必调用
.iterator().hasNext()或.stream().findFirst()触发真实加载，否则看不到异常（如 NoClassDefFoundError）
用业务层策略替代依赖加载顺序
ServiceLoader 遍历顺序由 classpath 中 JAR 的加载顺序决定，JVM 不保证稳定。不能靠“第一个就是默认实现”做逻辑分支：
- 让每个实现类提供
int getOrder()或String getProfile()方法，用于排序或匹配环境标识 - 在业务代码中统一收集全部实例：
loader.stream().filter(this::isActive).sorted(comparing(MyService::getOrder)).collect(toList()) - 通过配置项（如
auth.provider=jwt）控制启用哪个实现，而不是靠是否出现在 classpath 中来判断
与 Spring 等容器协同的关键处理
ServiceLoader 创建对象不走 Spring 容器，@Autowired 字段为 null，@PostConstruct 不执行：
- 若需 Spring 管理，不要直接用 ServiceLoader 返回的对象，而是用它做“发现器”：先查出所有实现类名 → 再调用
applicationContext.getBean(implClass) - 前提是这些实现类本身已被 Spring 扫描（如加了
@Component），否则需手动注入依赖 - 更轻量的做法是定义初始化接口（如
InitializingPlugin），在 ServiceLoader 加载后显式调用init(config)注入必要依赖
