SPI 通过线程上下文类加载器（TCCL）实现跨层级受控服务发现，支撑多数据库自适应脚手架：稳定层定义接口，扩展层提供各库实现，装配层按需加载；需显式管理 TCCL、自动路由、fallback 机制及可观测性保障。
利用 SPI 破坏双亲委派模型的“红利”，本质不是绕过安全机制，而是借力线程上下文类加载器（TCCL）实现跨层级的、受控的服务发现——让核心模块（如 JDBC DriverManager、统一 SQL 执行器）能安全加载用户路径下的数据库驱动和适配器。这套能力可直接沉淀为多数据库自适应脚手架的核心支撑层。
明确脚手架的三层职责边界
避免把“SPI”当成万能胶水，先划清责任：
-
稳定层：定义统一接口（如
DatabaseExecutor、ConnectionPoolFactory），放在基础 SDK 模块中，由系统类加载器或引导类加载器（如需嵌入 JDK 工具类）加载； -
扩展层：各数据库实现（MySQL、PostgreSQL、StarRocks、达梦、OceanBase）各自打包为独立 JAR，在
META-INF/services/com.example.db.DatabaseExecutor中声明实现类全名； -
装配层：运行时通过
ServiceLoader.load(DatabaseExecutor.class, Thread.currentThread().getContextClassLoader())加载，不硬编码、不反射 new，也不依赖 Spring 容器。
用 TCCL 锁定应用级类加载器上下文
关键动作不是“破坏”，而是“显式委托”。很多脚手架失败，是因为在非主线程或容器环境中丢失了 TCCL：
- 启动时主动设置：
Thread.currentThread().setContextClassLoader(getClass().getClassLoader());（尤其在 Java Agent、JAR 启动或非 Spring 环境下）； - 线程池任务中透传 TCCL：
new ContextClassLoaderAwareRunnable(runnable, Thread.currentThread().getContextClassLoader())； - Web 场景（如 Tomcat）注意：Servlet 初始化阶段的 TCCL 默认是 WebAppClassLoader，但 Filter/Listener 中若起新线程，需手动继承。
构建可插拔的数据库路由与执行链
SPI 提供的是“发现”，脚手架要补足“决策”和“兜底”：
- 支持基于 URL 前缀自动匹配：解析
jdbc:mysql://→ 加载 MySQL 实现，jdbc:dm://→ 加载达梦实现； - 允许配置默认实现 + 备用实现（防单点失效），例如当 PostgreSQL 驱动加载失败时，自动 fallback 到 H2 内存库用于单元测试；
- 每个实现提供
supports(String jdbcUrl)方法，由脚手架统一调用判断兼容性，而非靠异常兜底； - 连接池、事务管理、SQL 日志等横切能力，通过装饰器模式（如
TracingDatabaseExecutor）叠加，所有装饰器也走同一套 SPI 加载机制。
规避常见陷阱与增强可观测性
生产级脚手架必须暴露加载过程，否则问题难定位：
- 启动时打印所有已加载的
DatabaseExecutor实现及其 JAR 路径，标注是否被选中； - 捕获
ServiceConfigurationError和NoClassDefFoundError，包装为带类加载器快照的自定义异常（含 parent、loader name、URLs）； - 禁止在
static {}块中触发 ServiceLoader —— 此时 TCCL 可能未就绪，应延迟到首次getConnection()时按需加载； - 对国产数据库（如人大金仓、南大通用）特别处理：它们常重写 JDBC Driver 类，需确认其
DriverManager.registerDriver()是否兼容 TCCL，必要时封装一层代理 Driver。
这套设计不依赖任何框架，最小仅需 JDK 8+，却能支撑从开发测试（H2）、信创环境（达梦/人大金仓）到云原生（TiDB/StarRocks）的全场景切换。真正红利在于：新增一个数据库，只需发布一个 JAR 包，改一行配置，重启即可生效——类加载的事，交给 TCCL；业务的事，留给接口。
