企业官网建设流程全解析

1. SPI机制到底是什么：先把它放进一个真实场景里

我最早接触SPI（Service Provider Interface）时，第一反应是"这不就是配置工厂类吗"？后来在项目里被一个看似简单的问题折腾到深夜：短信服务商要从A换到B，顺手还要支持未来可能接入的C。最开始的做法很朴素——写一个SmsSender接口，然后用if-else在业务代码里判断当前用哪家：

if (config.getProvider().equals("aliyun")) { return new AliyunSmsSender(); } else if (config.getProvider().equals("tencent")) { return new TencentSmsSender(); }

两周后第三家接入，改代码、改测试、重新发布。又过了一个月，第四家来了，这次我真的受够了。更麻烦的是，如果你的平台是给多方做集成的，对方希望在不改你核心代码的情况下插入自己的实现，if-else根本没法满足。

这就是SPI机制生来要解决的问题：让接口的调用方与实现方彻底解耦。调用方只依赖接口，实现方通过约定的配置文件"自我声明"，程序运行时由系统自动发现、加载、实例化这些实现。注意这里的关键词是"发现"——不是你自己new出来的，也不是通过配置中心下发类名再反射创建，而是由一套规范化的加载器扫到它、拉起来、交给你。

这个课题适合谁？你不是只想要看懂《Java开发手册》里那条"使用SPI机制实现对实现类的扩展"，而是想真正搞清楚：为什么JDBC驱动加载不需要Class.forName了？为什么Spring Boot里一个jar包放入classpath就能自动生效？为什么日志框架换了绑定实现不用改业务代码？这几个问题的底层，全是或类似SPI这套思路。这篇文章我不会只讲概念，会把从原理、完整代码到应用场景、踩坑排查全流程过一遍，你可以直接照着抄进自己的项目。

1.1 先给SPI一个通俗的定义

SPI全称Service Provider Interface，直译是"服务提供者接口"。它是Java平台内置的一种服务发现机制，约定：

• 服务方（框架作者、平台方）定义一套接口，作为扩展点。
• 第三方（实现方）写实现类，并把实现类的全限定名写在约定的配置文件中。
• 系统通过java.util.ServiceLoader读取配置文件，加载并实例化实现类。

通俗理解，SPI就像"插座和插头"之间的关系。插座接口标准是固定的（接口本身），真正通电的是插头（实现类），谁家的插头符合这个标准就可以插进来用，插座这边完全不需要知道"插头是哪家工厂做的"。业务代码把插座买回来通上电，插头靠符合规格自己上门。

1.2 SPI是"翻过来的API"：两者的本质区别要分清

很多人混淆API（Application Programming Interface）和SPI，这里必须掰扯清楚。一句话概括：API是"你调用我"，SPI是"我调用你"。

• 在API模式下，接口的定义和实现通常由一方完成，调用方按照接口写代码发起调用，主动权在调用方。
• 在SPI模式下，接口的定义方（平台方）把接口暴露给外部，真正提供实现的是第三方。平台方写好的业务逻辑反而是通过ServiceLoader去"主动寻找"第三方的实现类来执行。

举一个实际例子：JDBC。java.sql.Driver接口由Java标准库定义，这是一套"插头标准"；各个数据库厂商（MySQL、PostgreSQL、Oracle）各自写自己的Driver实现。你的应用代码使用DriverManager获取连接，DriverManager内部通过SPI自动发现数据库厂商提供的Driver实现。你的业务代码从始至终没有import任何一个厂商Driver类，只依赖标准库的接口和DriverManager。这就是SPI的设计意图：平台方（JDK）不知道也不关心有哪些数据库厂商，但给所有厂商留好了一套扩展通道。

对比下来：

1.3 JDK SPI的工作流程与核心约定

JDK SPI机制自Java 1.3就存在（ServiceLoader从1.6正式放入java.util包），它的完整约定非常精简，核心就三步：

1. 提供一个公开的接口或抽象类，作为服务接口。
2. 在classpath下的META-INF/services/目录中，创建一个以服务接口全限定名命名的文件。文件内容每行写一个服务实现类的全限定名，支持#开头的注释行，必须是UTF-8编码。
3. 调用ServiceLoader.load(接口.class)获取迭代器，遍历该迭代器即可得到所有实现类的实例。

这三步听起来简单，但里面埋了不少细节。比如文件名为什么必须是全限定名？因为如果只写简单类名，两个不同包下的同名接口就撞了；而全限定名天然全局唯一，ServiceLoader可以直接用这个文件名去classpath里精确匹配资源。

再比如ServiceLoader的加载时机。ServiceLoader.load()本身不会立刻加载实现类，它返回的是一个懒加载的迭代器。真正触发加载是在你调用iterator.hasNext()或next()的那一刻。你看，一个看似简单的机制，设计上处处是稳定性考量，避免了一启动就把不用的实现类全都实例化一遍。

注意：实现类必须提供一个public无参构造器。ServiceLoader实例化时调用的是Class.newInstance()或构造器反射，如果实现类没有无参构造器，加载时会抛异常。

2. 实战！从零手写一个完整的JDK SPI示例

概念讲完了，不抄一遍代码等于没学会。我带你完整写一个SPI短信服务的小项目，包含接口、实现、配置文件、加载器和测试。这个例子参考了我在实际项目中做支付渠道接入时使用的模式，麻雀虽小五脏俱全。

2.1 项目结构与准备

不需要任何框架依赖，纯JDK即可验证，你只需要一个标准Java工程。我用的是Maven，目录结构如下：

spi-demo ├── pom.xml ├── src │ └── main │ ├── java │ │ └── com │ │ └── example │ │ ├── sms │ │ │ ├── SmsSender.java │ │ │ ├── AliyunSmsSender.java │ │ │ └── TencentSmsSender.java │ │ └── application │ │ └── SmsServiceInvoker.java │ └── resources │ └── META-INF │ └── services │ └── com.example.sms.SmsSender

很多人第一次写SPI会在这一步翻车：META-INF/services的路径拼错，或者目录名大小写不对。记住，services的s是小写！它是META-INF/services而不是META-INF/Services。Linux环境下目录大小写敏感，拼错就直接加载不到。

2.2 定义服务接口

package com.example.sms; /** * 短信发送服务接口 —— 这是SPI中的"服务接口" */ public interface SmsSender { /** * 发送短信 * * @param phone 手机号 * @param content 短信内容 * @return 是否发送成功 */ boolean send(String phone, String content); }

这里我的建议是，尽量做一个小而稳定的接口。接口方法越少、职责越单一，实现方往上的成本就越低。我在真实项目中见过一个SPI接口定义了十多个方法，结果每个新实现方都要费劲地空实现一堆方法，这违背了SPI"易于扩展"的本意。

2.3 写两个服务实现类

package com.example.sms; public class AliyunSmsSender implements SmsSender { public AliyunSmsSender() { System.out.println("AliyunSmsSender 已初始化"); } @Override public boolean send(String phone, String content) { // 模拟调用阿里云短信网关的HTTP接口 System.out.println("通过阿里云短信服务发送短信 -> " + phone + " : " + content); return true; } }

package com.example.sms; public class TencentSmsSender implements SmsSender { public TencentSmsSender() { System.out.println("TencentSmsSender 已初始化"); } @Override public boolean send(String phone, String content) { // 模拟调用腾讯云短信网关的HTTP接口 System.out.println("通过腾讯云短信服务发送短信 -> " + phone + " : " + content); return true; } }

注意构造器都展示出来了，就是为了强调无参构造器这个硬性要求。另外我把初始化日志写在构造器里，方便你观察ServiceLoader实例化实现的时机——后面讲懒加载时你会用上。

2.4 编写SPI配置文件

在src/main/resources/META-INF/services/目录下，创建文件名为com.example.sms.SmsSender的文件，内容为：

# 短信服务实现提供者列表，每行一个实现类 com.example.sms.AliyunSmsSender com.example.sms.TencentSmsSender

文件内容的顺序是有现实意义的：ServiceLoader返回的迭代顺序，恰好是配置文件里的声明顺序（严格说是配置资源文件内部的顺序）。这一特性在实现"多个实现的优先级、默认选第一个"这类需求时可以直接利用。

如果你的项目是Maven多模块，配置文件建议放在provider模块的resources下，哪边引入provider模块，哪边就自然拥有了这个实现。这种方式也是大型项目里"模块解耦+按需打包"的常用套路。

2.5 使用ServiceLoader加载实现

package com.example.application; import com.example.sms.SmsSender; import java.util.ServiceLoader; public class SmsServiceInvoker { public static void main(String[] args) { // 加载所有SmsSender实现 ServiceLoader<SmsSender> smsSenders = ServiceLoader.load(SmsSender.class); System.out.println("--- 开始遍历发送 ---"); // 遍历调用每个实现 for (SmsSender sender : smsSenders) { boolean success = sender.send("13800138000", "您的验证码是 9527"); System.out.println("发送结果: " + success); } } }

运行main方法，你会看到输出：

--- 开始遍历发送 --- AliyunSmsSender 已初始化 通过阿里云短信服务发送短信 -> 13800138000 : 您的验证码是 9527 发送结果: true TencentSmsSender 已初始化 通过腾讯云短信服务发送短信 -> 13800138000 : 您的验证码是 9527 发送结果: true

注意观察：遍历到哪个实现才打印对应构造器日志，说明实现类不在ServiceLoader.load()时就创建，而是在迭代时逐个实例化。这正是ServiceLoader设计上的懒加载特性，避免了启动期的无谓开销。

如果你换一个需求——"当前只加载第一个实现"，可以这样写：

ServiceLoader<SmsSender> smsSenders = ServiceLoader.load(SmsSender.class); SmsSender first = smsSenders.iterator().next();

实际项目中，"取第一个"这个语义很常见，因为很多SPI的配置顺序就代表优先级顺序。

提示：运行后如果什么都没输出，先检查resources目录在IDE中是否被正确标记为资源根目录。Maven项目默认src/main/resources会被打包，但老版本的Eclipse或者非标准工程里有时候会漏mark，这是我见过最多"代码写对了但是加载不到"的原因之一。

3. 你每天都在用：四个典型的使用场景拆解

手写示例的意义在于让你建立对机制的直观感受。但SPI真正的价值，要看它在Java生态中那些"无处不在"的落地场景。我选四个使用频率最高、最能代表这套思想的场景，挨个讲清楚它们各自是怎么用SPI的。

3.1 JDBC驱动加载：最经典的SPI落地案例

我们先回到JDBC。在老版本的Java里，JDBC连接MySQL必须写这么一行：

Class.forName("com.mysql.jdbc.Driver");

这行代码的目的是手动把Driver类加载进JVM，Driver类里的静态代码块会创建实例并注册到DriverManager。

但从JDBC 4.0开始，这行代码可以省掉了。你只需要拿到一个空的Connection连接，前提是mysql-connector的jar包在classpath里。为什么？看mysql-connector.jar里有个文件：

META-INF/services/java.sql.Driver

文件内容是一个实现类全限定名：

com.mysql.cj.jdbc.Driver

再看JDK的DriverManager源码（关键流程）：它有一个静态初始化块调用了ServiceLoader.load(Driver.class)，把classpath下所有jar包里注册的Driver实现全部加载并注册。所以流程就成了：Connection接口由JDK定义，Driver接口也是JDK定义；MySQL厂商只要把实现类放进jar并写上services文件，开机即自动生效，JDK不需要有任何数据库链接的具体实现。

这就是SPI“定义标准和自发发现”的典型案例。你仔细想想，如果没有SPI，Java核心库就得认识MySQL、Oracle、PostgreSQL的类名，这不乱套了吗。现在JDK的知识面是干净的：它只定义了"插座的形状"，插牌的事完全由厂商来做。

3.2 日志门面SLF4J的绑定与实现加载

你项目里可能这么打日志：

logger.info("user logged in: {}", userId);

这里的logger是SLF4J的API，它不是日志实现，实现是Logback或Log4j2。这个"API与实现分离"背后，SLF4J 2.x用的正是SPI机制。

在SLF4J 2.x版本中，logback-classic的jar包里有一个文件：

META-INF/services/org.slf4j.spi.SLF4JServiceProvider

文件内容是ch.qos.logback.classic.spi.LogbackServiceProvider。当你的classpath里放入了logback-classic，SLF4J的LoggerFactory会通过ServiceLoader发现这个Provider，用它来构建Logger。你如果换成log4j-slf4j-impl，它内部也带着自己的services文件，SLF4J就会自动切换到底层实现。换日志框架，业务代码一行都不用改。

其实看到这里你应该意识到一个规律：凡是有"门面/核心定义方+多个厂商/实现方"的生态，几乎都能看到SPI的影子。SLF4J充当门面，日志实现是厂商，业务代码只是调用方。

3.3 Spring Boot的Spring SPI：改良升级版

严格说，Spring Boot主要用的不是JDK原生ServiceLoader，而是自己实现的SpringFactoriesLoader。但它背后的思想与SPI一脉相承：在jar包的META-INF/spring.factories文件里声明一堆工厂类或自动配置类，Spring Boot启动时扫描所有jar包里的该文件并按需实例化。

后来Spring Boot 2.7又引入了新的自动配置声明机制：

META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports

里面每行写一个自动配置类的完整类名：

com.example.demo.config.MyAutoConfiguration

Spring Boot启动时通过SpringFactoriesLoader或AutoConfigurationImportSelector把classpath里所有jar包中此文件的内容收集到一起，再按条件装配。有了这套"Spring SPI"，你才能做到：引入一个spring-boot-starter-data-redis，RedisTemplate自动就组装好了；引入一个自定义starter，里面的自动配置类无需手动@Import就生效。

对比JDK SPI与Spring SPI，Spring SPI做了几处升级：

• 支持按类名从加载的配置值中创建对象，并放入Spring容器统一管理。
• 自动配置类之间可以通过@ConditionalOnClass、@AutoConfigureBefore等做条件装配和顺序控制。
• 配置内容不局限于一行的实现类名，可以包含复杂的元信息（比如自动配置类的优先级分组）。

所以如果你在Spring环境里做扩展，我通常建议优先考虑Spring的SPI，它能拿到Bean管理等能力。JDK SPI解决"发现"问题，Spring SPI解决"发现+装配+条件化"问题。

3.4 微服务框架里的扩展点设计：从JDK SPI到自定义ExtensionLoader

在很多微服务框架（比如Dubbo这类）里，你同样会看到"扩展点"的影子。Dubbo并没有直接用JDK的ServiceLoader（原因后面说），而是自己写了一套更强大的ExtensionLoader。核心思路却还是SPI那套：

• 框架定义了大量扩展点接口，比如协议Protocol、负载均衡LoadBalance、序列化Serialization。
• SPI配置文件声明多个实现，比如在jar包内某目录下以接口名为文件名写实现类列表。
• Dubbo根据@SPI注解和key在运行时动态选择具体扩展实现。

这套机制和JDK SPI的核心差异是：扩展加载器支持按名称获取某个具体实现，还能给扩展配别名、做依赖注入。这种私有SPI机制的出现，本质上就是为了解决JDK SPI不够灵活的问题——它只会一股脑地加载全部实现，而你很多时候只想按key取一个。

3.5 其他值得说的场景

除了以上四大类，SPI思想也散落在很多角落：

• JCA（Java Cryptography Architecture）的加密服务提供者，通过java.security.Security的provider机制注册加密算法实现。
• 字符集Charset.forName()在Java 9开始支持通过Module系统发现Provider，背后也是SPI那一套。
• 很多应用层插件系统，比如工作流引擎的自定义任务处理器，通过SPI自动登记自己的处理器实现，让核心引擎完全无感知。
• 测试框架里的报告器、序列化框架的序列化器、消息中间件的连接器，凡是"核心稳定、外围易变"的地方都有SPI的用武之地。

判断一个场景要不要用SPI，我在实战中习惯问三个问题：第一，接口的实现在编写核心代码时是否未知？第二，是否需要支持多个不同实现由使用方自由组合？第三，能否容忍实现方仅仅通过放个jar包+配置文件就完成接入？三个都满足，SPI就是合适的解法。

4. 进阶指南：JDK SPI的局限性与实战选型

SPI不是银弹，它那些"自动发现"的优点，在某些场合反而会成为痛点。我用得越久，越觉得需要先用透它的边界，再决定用不用。下面把JDK SPI的主要局限和不同场景下的替代方案讲清楚。

4.1 JDK SPI的几个"坑"

第一，配置文件写错悄悄失效。ServiceLoader扫描不到匹配的资源配置文件时，返回的是一个空迭代器，它不会抛异常。你遍历不到任何实现，打印个空集合就完事了。如果实现方的jar包没被依赖，或者services文件名拼写不一致，代码“静默失效”的可能性非常高，排查成本不低。

第二，要么全加载，要么按顺序取，不能按名字取。JDK SPI的加载方式是把所有实现都new一遍。如果你只想用其中一个，其他实现也会被实例化一遍，白白消耗资源。更麻烦的是，如果某些实现类的构造器依赖外部环境（比如网络连接），这个实例化本来就不该发生。

第三，无法自动注入依赖。ServiceLoader通过无参构造器实例化实现类，它根本不知道Spring Bean、不知道构造器参数。你的SPI实现如果内部要调用其他服务，必须自己想办法持有这些依赖。这也是为什么很多真实项目里，SPI实现类里总要写一段手动获取Spring容器Bean的工具代码。在Spring环境里直接裸用JDK SPI，体验确实不算好。

第四，异常信息不够友好。如果某个实现类构造器抛了异常，ServiceLoader会抛出ServiceConfigurationError，但有时候根本看不出来是哪个类出了问题，尤其在多个实现连在一起遍历时。我调试时遇到过这种堆栈，毫无头绪，最后是逐个实现排查才找到元凶。

如果要在Spring环境下整合，一个实用做法是：用JDK SPI做自动发现，但发现完不直接使用，而是把它注册进Spring容器，由Spring统一管理后续的生命周期和依赖。

@Component public class SmsSenderRegistrar { @Bean public List<SmsSender> smsSenders() { List<SmsSender> senders = new ArrayList<>(); ServiceLoader<SmsSender> loader = ServiceLoader.load(SmsSender.class); for (SmsSender sender : loader) { senders.add(sender); } return senders; } }

这样SPI实现只要能实例化，后续交给Spring容器做代理、AOP、属性注入都是可控的。

4.2 不同场景的选型建议

如果项目内部只是几个实现来回切换，没有“第三方需要接入”这种开放需求，我甚至不建议上SPI。直接用策略模式或工厂模式，代码可读性反而更好。SPI的价值在于开放性和可插拔性，没有扩展点和多方生态，它就是多余的复杂度。

4.3 从Java模块系统看SPI的另一种形态

Java 9引入的模块化系统（JPMS）提供了一套更规范的SPI形态：uses和provides。

在模块声明里：

module com.example.core { exports com.example.sms; uses com.example.sms.SmsSender; } module com.example.aliyun.provider { requires com.example.core; provides com.example.sms.SmsSender with com.example.aliyun.AliyunSmsSender; }

通过ServiceLoader.load(SmsSender.class)依然可以加载到provides声明的实现。JPMS把SPI的声明从“magic配置文件”提到了模块描述层的类型安全级别，编译器可以帮你校验。但说实话，目前绝大多数项目还没完全转向JPMS，传统jar包的META-INF/services方式依然是绝对主流。知道有这么个形态就够了，真遇到模块化项目时，能看懂模块描述文件不慌就行。

5. 排查笔记：我踩过的SPI相关疑难杂症

所有讲原理的文章最后都会落到实操。SPI本身简单，但"加载不到实现"这类问题在真实项目中出现的频率不低。我把这几年遇到的典型问题整理成一份速查笔记。排查思路是按概率从高到低排列的，你可以照着顺序查。

5.1 ServiceLoader返回空迭代器，实现类一个都找不到

这是我见过最多的情况，也是SPI最容易被骂"不靠谱"的原因。按照这个顺序排查：

1. 确认目录名。是META-INF/services，不是META-INF/SERVICES，也不是META-INF/service。Linux下大小写敏感，这是首查项。
2. 确认文件名。文件名必须是接口的全限定名com.example.sms.SmsSender，不是简单名SmsSender，也不是实现类名AliyunSmsSender。这个点连很多工作了三五年的开发都会搞混。
3. 确认实现类有没有无参构造器。ServiceLoader通过无参构造器实例化，你声明了有参构造器又没写无参构造器，加载时抛异常。这个属于编译期不会报、运行期必炸的类型。
4. 确认provider模块有没有被打包。多模块项目里，services文件放在provider模块里，主程序没有依赖它，那自然加载不到。
5. 确认打包后的jar结构。用jar tf xxx.jar | grep META-INF/services看一下，文件是否真的进入了目标jar。特别留意IDEA或者Maven是否把resources目录exclude了。

提示：如果只想看类的加载路径，可以在启动参数上加-Djava.util.logging.config.file配合java.util.logging输出ServiceLoader的日志，但更快的办法是直接写一个main方法单步断点调试ServiceLoader.load()内部返回的Provider，IDE里跟踪一下资源查找过程。

5.2 有多个实现，但期望加载哪一个却不固定

JDK SPI本身没有优先级的概念，唯一可以控制的就是配置文件里的行顺序。然而一旦经过jar打包、classpath拼接，加载顺序在某些极端情况下不一定等于你在文件里看到的顺序。我在Maven多模块项目里遇到过：两个依赖jar都被打包进去，每个jar都有同一个接口的services文件，这时ServiceLoader按classpath顺序取资源，先扫到哪个jar就用哪个。

遇到这种多实现共存的情况，建议不要依赖“默认取第一个”这种隐式规则。在业务代码里自己定义明确的选型逻辑：

ServiceLoader<SmsSender> senders = ServiceLoader.load(SmsSender.class); SmsSender active = null; for (SmsSender sender : senders) { if ("aliyun".equals(sender.providerName())) { active = sender; break; } }

我在接口设计上有个习惯：SPI接口里加一个描述自身的关键方法，比如providerName()、priority()，让选型逻辑在业务侧可见、可控、可测试。比起藏在配置文件里的隐式顺序，显式字段让人安心得多。

5.3 实现类加载了，但它依赖的Bean和资源没法初始化

ServiceLoader只是无脑new一个对象，它不经过Spring容器。如果你的实现类内部需要注入Mapper、RedisTemplate等Spring Bean，你会拿到一堆空指针，因为那些Bean根本没人给它。

我踩过坑后给出的解决方案是分等级：

• 实现类内部尽量不依赖外部Bean，自己在构造时初始化轻量资源。
• 如果实在要依赖Spring Bean，把SPI实现注册进Spring容器统一管理，通过构造器注入或@Resource注入。
• 在加载完SPI实现后，通过ApplicationContext.getAutowireCapableBeanFactory().autowireBean(instance)手工完成依赖注入。

List<SmsSender> senders = new ArrayList<>(); ServiceLoader<SmsSender> loader = ServiceLoader.load(SmsSender.class); for (SmsSender sender : loader) { applicationContext.getAutowireCapableBeanFactory().autowireBean(sender); senders.add(sender); }

简单说，SPI只负责发现实现类，实现类之后的"生活质量"你要自己安排好。

5.4 类加载器问题与跨ClassLoader陷阱

在应用服务器、OSGi容器或复杂的classloader环境下，SPI还会遇到另一个经典问题：ServiceLoader.load(Class)使用的是调用方的上下文类加载器。如果框架代码（比如Tomcat容器内共享库）和实现类（应用lib里）处于不同的classloader层级，可能会加载不到服务实现。

一个治标的思路是显式指定类加载器：

ServiceLoader<SmsSender> loader = ServiceLoader.load(SmsSender.class, Thread.currentThread().getContextClassLoader());

治本的话，要理解你所在容器的classloader委托模型，保证services文件和实现类在同一个可见范围内。这个坑多数普通Web应用不会遇到，但在老式的Tomcat多应用部署或OSGi场景里是真实存在的。

5.5 排查速查表总结

排查的核心思路是：SPI的配置文件路径是硬约定，一切问题先检查路径和文件内容；加载过程是懒加载的，一切问题先确认迭代器真正被消费了；实例化是无参构造的，一切问题先确认实现类能被轻松new出来。记住这三条，大部分SPI问题都在十分钟内能定位。

最后分享一点个人体会。我见过很多项目在使用SPI时，只盯着"自动加载"这个便利，却没有规划好选型规则和失败兜底。真正让我对SPI改观的项目，是在一个需要接入多方短信、支付、存储提供商的平台系统里——核心代码只依赖极少数接口，每接一家新厂商，就是provider那边新增一个实现类和一行配置文件，核心代码零改动，测试也只需要针对性地跑新厂商的模块。那之后我就形成了一个判断标准：当一个系统里"核心功能稳定、外围提供方不断增多"时，SPI就是从图纸到代码都值得坚守的方案。反过来说，当你只需要两个实现且团队只有你自己维护时，写个工厂类比SPI清爽得多。工具本身没有高下，选择它的时机，才真正体现你对这套机制的理解。