JSP连接Access数据库全攻略：从JDBC-ODBC桥到UCanAccess驱动
2026/10/16 23:25:27
接手一个维护了四五年的老项目，最先要干的事通常不是写新功能，而是先摸清楚它底下那些历史遗留的注册机制有没有互相打架。我第一次在同一份代码里同时看到META-INF/spring.factories和META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports两个文件时，整个人是有点懵的：这俩到底谁说了算？同一个自动配置类两边都写了算重复吗？删掉其中任何一个会不会让生产环境静默缺 Bean？
这些问题如果没有彻底搞清楚，后面每一次升级 Spring Boot 版本、加一个新 Starter，都会变成拆盲盒。这篇文章不打算复述官方文档，我只写自己在项目里排查、迁移、翻车之后留下的经验，尽量让你少走我走过的弯路。
1. 两个文件只干同一件事：向 Spring Boot 提交"自动配置候选名单"
1.1 自动装配不是靠包扫描，而是靠"注册表"机制
很多刚接触 Spring Boot 的人会天然觉得：既然叫自动配置，肯定是框架在启动时把 classpath 底下所有@Configuration类都扫描一遍，然后按需生效。这个直觉只对了一半。
@SpringBootApplication里的@ComponentScan确实会扫描，但它默认只扫描主类所在包及子包。你引入的第三方 Starter，比如数据源、Redis、消息队列相关的配置类，它们的包路径根本不在你的扫描范围之内。如果自动配置真的靠扫描，那所有 Starter 的配置类都必须被别人包进来，这既不现实也不安全。
所以 Spring Boot 换了一套思路：约定好一些固定的 classpath 资源位置，启动时从这些位置读取 "哪些类是自动配置候选类" 的名单，然后再用条件注解逐个判断，最终决定哪些类真正写入容器。这个机制就是AutoConfigurationImportSelector在做的事情。
我习惯把这套机制理解成一个"演出候选名单"：
- 名单是这个行业里所有 Starter 自己提交上来的，不是主办方满世界去搜的；
- 名单上只是候选人，最后能不能上台，还要看"条件注解"这个审核官点不点头；
- 名单的提交位置是固定的，谁不按位置提交，谁直接失去候选资格。
1.2 两个文件各自的"简历"
spring.factories是 Spring Framework 很早期的产品，在 Spring Boot 还没出生时，Spring Framework 就用它做 SPI 扩展加载。Spring Boot 继承了这套机制，把它当成了自动配置候选名单的存放地之一。
AutoConfiguration.imports是 Spring Boot 2.7 才引入的新文件，专门用于注册自动配置类。它和旧文件最大的区别是：一个文件只负责一件事，不掺杂其他 SPI 扩展点。
我把两者最关键的差异整理成了表格，方便你一眼定位：
| 对比维度 | spring.factories | AutoConfiguration.imports |
|---|---|---|
| 文件完整路径 | META-INF/spring.factories | META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports |
| 引入时间 | Spring Framework 3.0 时代 | Spring Boot 2.7 起 |
| 注册格式 | key=value 映射，自动配置的 key 是org.springframework.boot.autoconfigure.EnableAutoConfiguration | 每行一个类的全限定名，无 key 概念 |
| 服务范围 | 所有 Spring Boot SPI 扩展点（自动配置、初始化器、监听器、环境处理器等） | 只服务于自动配置类注册 |
| 解析方式 | 要解析整个文件，再按 key 挑出对应的 value | 按固定路径直接读取，只装载自动配置相关内容 |
| Broken 兼容 | Spring Boot 2.7 仍可用；3.x 起自动配置不再支持 | Spring Boot 2.7+ 可用；3.x 起成为唯一合法途径 |
你可能会想：既然旧文件用了这么多年，为什么官方还要搞一个新文件出来？答案不在文件本身的格式上，而在于 Spring Boot 2.x 后期对自动配置机制的重新整理。这件事我放到后面详细讲。
2. spring.factories 的黄金时代：为什么它能统治那么多年
2.1 它其实是 Spring Framework 留给 Spring Boot 的老家底
spring.factories的加载逻辑来自SpringFactoriesLoader，这个类在 Spring Framework 3.0 时代就存在了。它的做法是把所有 jar 包中META-INF/spring.factories文件加载成 Properties 格式，然后按 key 取值。
这种设计在最开始是合理的：当时 Spring Framework 生态里的扩展点并不多，一个统一的工厂文件就能装下所有扩展实现。但 Spring Boot 出现后，情况变得复杂了——自动配置本身就是巨大的扩展点，SpringFactoriesLoader一个文件既要服务自动配置，又要服务其他 SPI，慢慢就成了一个大杂烩。
一个典型的旧式spring.factories长这样：
org.springframework.boot.autoconfigure.EnableAutoConfiguration=\ com.example.projectx.autoconfigure.XxxAutoConfiguration,\ com.example.projectx.autoconfigure.YyyAutoConfiguration org.springframework.context.ApplicationContextInitializer=\ com.example.projectx.context.XxxApplicationContextInitializer org.springframework.boot.env.EnvironmentPostProcessor=\ com.example.projectx.env.XxxEnvironmentPostProcessor注意两个细节：
- 自动配置类之间用逗号分隔，行尾反斜杠表示续行；
- 同一个文件里可以塞多个不同的 key，各自服务各自的扩展点。
2.2 它不只是自动配置的名单，还是整个 Spring Boot 的 SPI 总表
这个点很容易被忽略。很多同学在升级到 Spring Boot 3.x 之后，发现spring.factories还在项目里躺着，就以为迁移没做干净。其实这是误解。
Spring Boot 3.x 移除了spring.factories里自动配置注册的能力，但并没有废掉整个文件。像下面这些扩展点，在 Spring Boot 3.x 里依然可以通过spring.factories注册：
ApplicationContextInitializer：在容器刷新前对上下文做定制；EnvironmentPostProcessor：在环境准备阶段修改配置源；ApplicationListener：注册自定义应用事件监听器；SpringApplicationRunListener：监听应用启动各个阶段；FailureAnalyzer：把启动异常翻译成人话。
所以严谨的说法是：spring.factories从你项目里完全消失，不代表它错了；只要里面没有org.springframework.boot.autoconfigure.EnableAutoConfiguration这个 key，它就是合法存在的。
2.3 在自定义 Starter 里，它是怎么驱动自动配置生效的
假设我要做一个"短信发送"的 Starter，核心自动配置类叫SmsAutoConfiguration。在没有新文件的年代，我需要做四步：
- 定义配置类和实际业务类；
- 在 Starter 模块的
src/main/resources/META-INF/spring.factories里写：org.springframework.boot.autoconfigure.EnableAutoConfiguration=\ com.example.projectx.sms.autoconfigure.SmsAutoConfiguration - 打包发布；
- 主应用引入坐标后，什么都不用写，启动时
AutoConfigurationImportSelector就会把这个类加入候选名单。
这个流程在今天依然成立，只是第四步读取的文件变了。旧机制的"自动发现"逻辑，本质上完全依赖文件名和 key 的约定，一旦某个人在spring.factories里拼错了一个 key 名，Spring Boot 不会给任何报错，只会静默忽略——这是旧机制最折磨人的地方。
3. AutoConfiguration.imports 的登场：Spring Boot 2.7 到 3.0 究竟改了什么
3.1 官方为什么要另起炉灶：旧文件的三宗原罪
我接触过的很多同学都问过同一个问题：spring.factories明明还能用，为什么要费劲迁移？这就要说到旧机制在规模化场景下的三个硬伤。
第一，职责混杂，性能和语义都吃亏。一个spring.factories文件里可能同时挂自动配置、监听器、环境处理器。任何模块往这个文件里加内容，Spring Boot 启动时都要完整解析一遍整个文件，然后按 key 精确匹配。虽然现代机器对这点开销不太敏感，但理念上它就是不干净——你想排查"自动配置为什么没生效"，却要先翻完一整个 SPI 总表。
第二，构建工具和 IDE 无法从 spring.factories 反推自动配置候选类。Maven、Gradle 在分析依赖时，能通过AutoConfiguration.imports这类固定路径文件快速知道某个依赖里藏着哪些自动配置类。而spring.factories是统一的 key-value 结构，意图不够显式，工具很难做静态分析。
第三，也最隐蔽的：多模块协作时容易互相覆盖。两个 jar 包都有META-INF/spring.factories，被依赖合并进 classpath 后，Spring 会合并所有文件内容。听起来没问题，但一旦有人在两个 jar 里用了同一个 key 且其中一个写错了，排查起来成本极高。
3.2 新文件的完整路径本身就是最好的文档
新文件的名字很长，看起来不好记，但它其实非常直白：org.springframework.boot.autoconfigure.AutoConfiguration.imports就是"给自动配置类用的 imports 文件"。它放在META-INF/spring/目录下，而不是 classpath 根目录，因为这个目录是 Spring Boot 约定给所有内部 SPI 文件共享的位置。
文件内容也简单到令人感动，就一行一个类全限定名：
com.example.projectx.autoconfigure.SmsAutoConfiguration com.example.projectx.autoconfigure.StorageAutoConfiguration没有冒号、没有等号、没有逗号，也不需要续行反斜杠。每一个类必须是能够在 classpath 中实际存在的类，否则当它被当成候选读取时，可能被条件注解挡住，也可能直接引发类加载问题。
3.3 2.7 是过渡期，3.x 是清算期
如果只记住一个时间线，请记住这个：
- Spring Boot 2.7：新文件加入，同时兼容旧文件。自动配置类在
spring.factories里依然合法； - Spring Boot 3.0：移除
spring.factories中对自动配置注册的支持。你想注册自动配置类，只有AutoConfiguration.imports这一条路； - Spring Boot 3.x 后续版本：
spring.factories继续存在，但只服务非自动配置的 SPI 扩展点。
所以在 2.7 时代最稳妥的做法是"双写"：同一个自动配置类，既写进AutoConfiguration.imports，也保留在spring.factories。这样依赖你的老项目在 2.6 甚至更早的版本升不动时依然能用，而你自己的项目升到 3.0 后也没有历史包袱。
4. 两套文件同台共存的技术细节：优先级、去重与安全姿势
4.1 同一份代码里两个文件都写了，到底谁生效
这是我被问得最多的问题。答案可能跟很多人想的不一样：在 Spring Boot 2.7 这种双兼容阶段，AutoConfigurationImportSelector会同时读取两个来源，然后合并进同一个候选集合，Spring 内部是用 Set 做去重的，同一个类不会因为出现在两个文件里就实例化两次。
但不要因此就觉得双写是件可以随手做的事。最危险的情况出现在"两个文件里的类列表不完全一致"的时候，比如旧文件里配了 A、B 两个类，新文件里只写了 A。由于自动配置类的排序、条件评估都依赖完整候选集，B 在某些环境里可能会因为顺序变化产生完全不同的行为。这种问题不报错，只在特定条件组合下悄悄出现，排查起来非常恶心。
依赖 Spring 的去重机制去兜底，远不如把两份文件当成同一份源清单的两种渲染结果。
4.2 双写期真正安全的维护姿势：一份源清单，自动生成两个文件
我后来在团队里定的规矩很简单：自动配置类的清单只维护一个地方，然后通过脚本生成spring.factories和AutoConfiguration.imports。手工维护两份物理文件，迟早会在某次版本迭代里有一边漏改。
脚本逻辑大致是这样的：
# autoconfig-list.txt 是唯一源清单 cat autoconfig-list.txt com.example.projectx.autoconfigure.SmsAutoConfiguration com.example.projectx.autoconfigure.StorageAutoConfiguration生成AutoConfiguration.imports时直接逐行复制，生成spring.factories时则用逗号拼接后拼到 key 后面。这种"生成"的做法看起来多了一步，实际上救过我们很多次，因为再细心的人也会在第三次手工复制时漏一条。
4.3 自动配置类上的注解，别再用最老的那套
在 Spring Boot 2.7 之后，官方推荐使用@AutoConfiguration注解来标记自动配置类，而不是直接写最原始的@Configuration。@AutoConfiguration本身是@Configuration的封装，同时会参与自动配置排序机制。
配合它使用的仍然是老三个注解，规则没变：
@AutoConfigureBefore(XxxAutoConfiguration.class)：声明在本类之前评估；@AutoConfigureAfter(XxxAutoConfiguration.class)：声明在本类之后评估；@AutoConfigureOrder(Ordered.LOWEST_PRECEDENCE)：声明全局顺序。
@AutoConfiguration @ConditionalOnClass(name = "com.example.projectx.sms.SmsSender") @EnableConfigurationProperties(SmsProperties.class) public class SmsAutoConfiguration { @Bean @ConditionalOnMissingBean public SmsSender smsSender() { return new SmsSender(); } }你会发现，文件迁移只是第一步，真正决定自动配置类生效与否的，永远是类上的条件注解和顺序声明。文件只是"入场券"。
5. 迁移实战：老项目安全搬到新注册机制的完整排查链路
5.1 先摸清家底：全库扫描注册入口
迁移最忌讳"猜"。第一步是把项目里所有注册入口全部翻出来，一个都不能漏。我一般直接在项目根目录跑：
find . -path '*/target/*' -prune -o \( -name 'spring.factories' -o -name '*AutoConfiguration.imports' \) -print接着再精确搜索自动配置的 key：
grep -R "EnableAutoConfiguration=" --include="spring.factories" .扫描结果一般分三类：
- 你正在维护的自己的模块；
- 依赖的第三方公司内部 jar（如果你可以改）；
- 第三方开源构件（大概率改不了，只能升级版本）。
只有第一类是你本次迁移能控制的范围，第二类最好联系对应团队，第三类则直接去查目标版本是否已经使用新文件。
5.2 把 spring.factories 里的条目分成两个篮子
这一步是最关键的分类操作。把spring.factories里所有条目按扩展点归类：
| 扩展点 key | 迁移动作 |
|---|---|
org.springframework.boot.autoconfigure.EnableAutoConfiguration | 必须迁移到AutoConfiguration.imports |
org.springframework.context.ApplicationContextInitializer | 保留在 spring.factories |
org.springframework.boot.env.EnvironmentPostProcessor | 保留在 spring.factories |
org.springframework.context.ApplicationListener | 保留在 spring.factories |
org.springframework.boot.SpringApplicationRunListener | 保留在 spring.factories |
org.springframework.boot.diagnostics.FailureAnalyzer | 保留在 spring.factories |
这里最容易犯的错，是把整个spring.factories文件删掉，结果连带着初始化器和环境处理器一起失效，项目启动时配置源加载顺序直接乱了。
5.3 最小改动迁移顺序
我推荐按"小步快跑"的方式操作，每一步都有验证点：
- 新建
META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports； - 把
spring.factories里属于自动配置类的类名复制到新文件； - 确认两边的自动配置类名单完全一致；
- 从
spring.factories里删除EnableAutoConfiguration这个 key 及其全部 value； - 跑一遍全量单测和集成测试；
- 确认启动日志里的 Positive matches 和迁移前对比无差异。
翻译成人话就是：先把新名单建立起来，再让旧名单"退位"。两条名单在同一版本里并存的时间越短越好，因为双写总有漏改风险。
5.4 用日志和 Actuator 验证自动配置是否真的生效
自动配置生效与否，不能靠"我觉得项目能启动"来判断。很多自动配置类被条件注解挡住是正常的，但"候选类根本没进名单"和"候选类进了名单但条件不满足"是两回事。
最直接的验证方式是在application.properties里开自动配置的调试日志：
logging.level.org.springframework.boot.autoconfigure=debug启动后会看到详细的：
Positive matches：条件匹配成功的自动配置类；Negative matches：条件不匹配但进入评估的自动配置类；Exclusions：主动排除的自动配置类。
如果项目暴露了 Actuator 端口，还可以直接看/actuator/conditions端点，它可以让你在运行期查看完整的条件评估报告。排查"某个 Bean 为什么没创建"时，这个端点比看代码有用得多。
5.5 打包后别忘了检查最终产物
开发环境跑得通，不代表发布包没问题。Maven 的maven-jar-plugin或 Gradle 的jar任务在默认情况下会带上META-INF/spring.factories，但如果你把资源目录配错了，新文件可能根本没进 jar。
发布前用这行命令检查一下最终产物：
jar tf target/your-app.jar | grep -i 'AutoConfiguration.imports\|spring.factories'我见过太多次"本地复现不了、测试环境才出事"的反常现场，最后发现就是打包时把资源目录漏了。现在开发阶段就把检查命令写进流程里，能省掉后面一整个晚上的排查时间。
6. 三个典型的翻车现场，每一个都是真实教训
6.1 文件名写错一个字母，自动配置静默消失
当时有位同学在新建模块时，把文件命名成了org.springframework.boot.AutoConfiguration.imports，少写了autoconfigure包名。Spring Boot 启动的时候没有任何报错，因为它本来就是按固定路径去读文件，读不到就当作没有候选类，完全不吭声。
排查了整整一个下午才发现问题。这类问题最可怕的地方在于，它不以"报错"的形式出现，而是以"什么也没发生"的形式出现。想避免它，只能靠打包后检查jar tf输出，以及启动时看 debug 日志里有没有你的候选类。
6.2 老 Starter 被直接扔进 Spring Boot 3.0 项目里，全部自动配置失效
这是升级到 3.x 时最常见的坑。项目本身升级了，但某个内部 Starter 的发布版本还停留在只写spring.factories的旧时代。由于 Spring Boot 3.0 不再认spring.factories里的EnableAutoConfiguration键，这个 Starter 的自动配置类等于从名单上被抹掉了，而业务代码还在依赖这些 Bean，于是出现各种"奇怪的空指针"和"NoSuchBeanDefinitionException"。
最无奈的是，这类问题有时连异常都不会有——如果你的业务代码通过接口注入且做了可降级处理，可能只是某个能力悄悄不工作。我的排查建议很直接：升级 3.x 时，如果某个行为突然和升级前不一致，第一件事就是去看ConditionEvaluationReport，确认不是"候选类压根没有参加评估"。
6.3 双写期两边名单不一致，线上行为完全取决于打包顺序
还有一次，项目处于 2.7 的双兼容期，两个同事各维护了一个文件。一个人把新增自动配置类写进了spring.factories，另一个人把另一批类写进了AutoConfiguration.imports。表面上两者都能生效，但自动配置类的整体顺序被打乱了，导致一个@AutoConfigureBefore的语义没有按预期执行，容器里多出一个本应被覆盖的 Bean。
这种问题最不能忍的点在于：完全没有语法错误，也没有构建错误，只有运行期表现出微妙的差异。从那以后我才彻底坚持"源清单生成两个文件"的做法。技术上的兼容能力再好，也架不住人肉维护两份名单的粗心。
最后分享一个我们团队现在仍在用的小习惯：任何自定义自动配置类合并进主干之前，我都会把启动时Positive matches里出现的新增条目截图放评审记录里。看着不起眼，但在排查版本回归时，这张截图往往是最早定位问题的线索。自动配置机制从spring.factories迁移到AutoConfiguration.imports，本质上是一次把"隐式约定"变成"显式路径"的进步。如果你也在做类似的迁移，记住一点：文件迁移只是开始，真正值钱的是你愿意花时间把每一条自动配置的候选路径和生效条件都核对清楚。