第三方SDK硬编码类加载器导致ServiceLoader失效，因其绕过TCCL而无法加载业务模块的SPI实现；可通过劫持TCCL、调整classpath顺序或反射覆盖等方法临时修复，长期应改用接口抽象、动态代理或进程隔离等解耦方案。
第三方 SDK 内部硬编码了类加载器（比如直接用 ClassLoader.getSystemClassLoader() 或显式 new 一个特定 ClassLoader），会导致 Java 原生 ServiceLoader 失效——因为 SPI 依赖线程上下文类加载器（TCCL）去扫描 META-INF/services/ 下的配置，而硬编码的加载器往往跳过了当前业务模块的 classpath，自然找不到你写的实现类。这不是“SPI 不好用”，而是 SDK 破坏了 SPI 的运行前提。
确认是否真被硬编码锁死
先别急着重构或换 SDK，花 5 分钟验证问题根源：
- 在 SDK 相关初始化代码处打个断点，看它调用
Class.forName(...)或ClassLoader.loadClass(...)时，用的是哪个加载器（打印getClassLoader().toString()） - 检查它是否绕过了
Thread.currentThread().getContextClassLoader()，比如写死了MySdk.class.getClassLoader()—— 这种写法会绑定到 SDK 自身 jar 的加载器，无法看到你项目里的META-INF/services/ - 用
javap -v反编译 SDK 的关键类，搜getSystemClassLoader、AppClassLoader、new URLClassLoader等关键词，确认是否存在硬编码痕迹
绕过硬编码加载器的三类实操路径
不改 SDK 源码也能破局，关键是把你的实现“塞进它认得的类路径”里：
-
劫持 TCCL 临时生效：在调用 SDK 初始化前，用
Thread.currentThread().setContextClassLoader(yourClassLoader)把你项目的类加载器设为上下文加载器；注意要在 SDK 第一次触发服务发现前完成，且调用后及时恢复原 TCCL，避免影响其他组件 -
把实现类打进 SDK 同级 classpath：把你写的 SPI 实现类和
META-INF/services/xxx.Interface文件，一起打包进一个独立 jar，并确保该 jar 在 classpath 中排在 SDK jar 之前（Maven 依赖顺序、启动脚本 -cp 顺序都影响）；这样 SDK 即使用自己的加载器，也能从父加载器（或并行加载器）中查到服务配置 -
用反射覆盖其内部加载器字段（慎用）：如果 SDK 暴露了可访问的加载器成员变量（如
private static ClassLoader loader），可通过Field.setAccessible(true)替换为支持 TCCL 的实例；仅限测试环境验证可行性，线上需充分评估稳定性风险
长期可用的解耦替代方案
若 SDK 频繁更新、硬编码逻辑顽固，建议放弃“强塞 SPI”，转向更可控的集成方式：
-
接口抽象 + Spring 条件装配：将 SDK 的能力封装成标准接口（如
PaymentService），用@ConditionalOnProperty或@ConditionalOnClass控制不同实现（官方 SDK / 你自研适配层 / Mock）的自动注入，完全绕开其内部类加载逻辑 -
动态代理 + 接口委派：用
Proxy.newProxyInstance()创建 SDK 接口的代理对象，在invoke()中根据运行时条件（如配置开关、环境变量）决定调用真实 SDK 实例还是你提供的兜底实现，类加载由你完全掌控 - 进程/模块级隔离：对高危或不可控 SDK，用独立子进程（Java Process）、gRPC 微服务或 Android 的独立进程方式调用，主应用只通过标准协议通信；虽增加复杂度，但彻底规避类加载污染和崩溃传染
硬编码类加载器不是死局，是提醒你：SPI 的契约前提是“双方遵守 TCCL 规则”。当一方违约，就该换契约——用更明确的控制权接管代替隐式约定。
