ServiceLoader 通过严格查找 META-INF/services/接口全限定名 文件来发现实现类，要求路径、大小写、包分隔符（点号）完全匹配，文件内容为每行一个实现类全限定名，末尾无空格或 BOM；采用懒加载，仅在调用 iterator().next() 时反射实例化，且不管理依赖注入或生命周期。
ServiceLoader 是怎么找到实现类的
它不靠扫描整个 classpath，而是严格按路径找：META-INF/services/接口全限定名。比如接口是 com.example.Search，它就只查 META-INF/services/com.example.Search 这个文件是否存在、是否可读。
常见错误现象：NoClassDefFoundError 或服务根本没加载出来，八成是路径写错——不是 META-INF/services/com/example/Search（用斜杠），也不是 resources/META-INF/services/xxx 放在子模块却没打进 jar；更不是文件名大小写错了（Linux 下敏感）。
- 文件必须放在
resources目录下（编译后进 classpath 根目录），不能放 src/main/java 里 - 文件名必须和接口全限定名完全一致，包括大小写和包分隔符（点号）
- 文件内容每行一个实现类全限定名，末尾不能有多余空格或 BOM 头（Windows 记事本易加）
- 如果多个 jar 都提供了同一接口的实现，
ServiceLoader会全部加载，顺序取决于类加载器 getResources() 返回的 URL 列表顺序，不可预测
为什么 new ServiceLoader(iface, cl) 不直接实例化所有实现
它用的是懒加载：调用 iterator().hasNext() 或 iterator().next() 时才真正解析配置、反射创建实例。好处是避免无谓初始化；坏处是——第一次 next() 可能抛 NoClassDefFoundError 或 InstantiationException，而你此前根本不知道有这个类存在。
典型陷阱：写了个工具类封装 ServiceLoader.load(XXX.class) 并缓存了 loader 实例，但没调用 iterator()，结果下游以为“已加载成功”，实际运行时才崩。
- 不要提前缓存
ServiceLoader实例并假设它已就绪；每次需要服务时，建议重新ServiceLoader.load() - 若需预检可用实现，必须显式遍历
iterator()并捕获异常，不能只靠hasNext() - 构造时传的
ClassLoader很关键：默认用Thread.currentThread().getContextClassLoader()，Web 应用中若线程上下文类加载器被重置（如 Tomcat 的 webapp 类加载器未设为上下文），就会找不到自己 jar 里的实现
ServiceLoader 和 Spring @Autowired 的本质区别在哪
ServiceLoader 是 JVM 层的静态发现机制，不依赖任何框架，也不管 Bean 生命周期；@Autowired 是 Spring 容器管理的动态注入，支持代理、AOP、作用域等。两者混用容易出问题：比如你用 ServiceLoader 加载了一个实现类，但它内部又依赖了 Spring 管理的 @Service，那这个依赖不会自动注入，直接 NPE。
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
常见误用场景：在 Spring Boot Starter 中暴露 SPI 接口，想让用户自定义实现并自动纳入容器管理——ServiceLoader 做不到这点，它只负责 new 出来，不走 Spring 创建流程。
- 若需 Spring 管理 SPI 实现，得额外写
@Configuration类，用ServiceLoader扫描后手动注册为@Bean - Dubbo、ShardingSphere 等框架都绕开了纯
ServiceLoader，自己实现扩展加载器，核心就是为了控制实例生命周期和依赖注入时机 - 别指望
ServiceLoader支持条件加载（如@ConditionalOnClass）、优先级排序或 fallback 默认实现——它连配置项都不认
为什么 JDBC 驱动不用 Class.forName 就能工作
从 Java 6 开始，DriverManager 内部就是用 ServiceLoader.load(Driver.class) 加载驱动的。MySQL 8+ 的 com.mysql.cj.jdbc.Driver 在其 jar 包里自带 META-INF/services/java.sql.Driver，内容就是自己类名。所以你只要把 mysql-connector-java.jar 放进 classpath，DriverManager.getConnection() 就能自动触发加载。
旧写法 Class.forName("com.mysql.jdbc.Driver") 是 Java 5 及之前必须的手动注册方式，现在不仅多余，还可能因类加载器隔离失败而静默失效（尤其 OSGi 或模块化环境）。
- Spring Boot 2.4+ 默认禁用自动驱动注册，改由
DataSource初始化时通过ServiceLoader查找，因此删掉Class.forName不仅安全，而且更健壮 - 如果你自己写数据库中间件，别重复造轮子去 scan 包，直接复用
ServiceLoader即可，标准、轻量、无额外依赖 - 注意：JDBC SPI 文件里只能写一个驱动类（尽管规范允许多个），否则
DriverManager可能选错实现——这是 MySQL 和 PostgreSQL 驱动各自 jar 独立提供文件的根本原因
SPI 机制看着简单，但真正在多模块、多类加载器、混合框架环境下跑通，关键不在“能不能写出来”，而在“谁的类加载器在什么时候加载了哪个 jar 里的哪行配置”。这点不厘清，90% 的加载失败都卡在这儿。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
