SPI

为什么是 SPI 做框架开发时，经常需要让外部团队在不改源码的情况下插入自定义逻辑。Java 的 Service Provider Interface（SPI）正是解决这一痛点的经典方案：框架只暴露接口，具体实现由使用者提供，双方通过约定的加载机制解耦。 下图展示了 SPI 的角色关系： 框架接口 --> 服务提供者实现 --> 应用在运行时按需调用 | | | API 定义 resources/META-INF/services ServiceLoader 按需加载 框架负责定义接口与约定，提供者将实现类打包好，ServiceLoader 在运行时装配，两端互不感知彼此细节。 SPI 与 API 的区别 API：框架写好实现，并通过方法开放给调用方使用。 SPI：框架只制定契约，由外部提供实现，框架在运行时回调实现。 因此 SPI 更适合“我要在某个节点上让别人接管”的场景，比如数据库驱动、日志实现、路由策略等。 Java 里的落地步骤 定义接口：在框架模块中写出需要开放的契约。 制定注册文件：在 resources/META-INF/services 目录下，新建以接口全限定名命名的文件，内容是实现类的全限定名。 加载实现：使用 ServiceLoader.load(Interface.class) 遍历可用实现。 按需调用：框架可以根据配置挑选实现，或全部加载做聚合处理。 代码示例： ServiceLoader<MyExtension> loader = ServiceLoader.load(MyExtension.class); for (MyExtension extension : loader) { extension.handle(request); } 这种方式天然支持多实现并存，也可以搭配权重、标签等策略做更细粒度的路由。 经验分享 约定胜于配置：接口命名尽量描述清楚输入输出，让实现方知道该承担的责任。 尽早校验实现：在框架启动阶段做初始化测试，确保缺失依赖时能及时报错。 限制加载范围：按需使用自定义的 ClassLoader，避免整个应用 ClassPath 都被扫描，启动速度更可控。 配合缓存：ServiceLoader 支持懒加载，常驻的服务实现可以二次封装成缓存，减少重复实例化。 适用与注意事项 SPI 并非银弹。它适用于以下场景： ...