Spring Boot 3升级遇factoryBeanObjectType异常：根因与修复指南

1. 先看清异常现场：什么阶段报、长什么样、谁最容易触发

升级完依赖、重新编译、启动，Tomcat 都开始打印端口号了，结果日志里一闪而过一行Invalid value type for attribute 'factoryBeanObjectType': java.lang.String，整套应用瞬间退出。这个错误是 Spring 6 / Spring Boot 3.x 升级过程中最典型的兼容性报错之一。它不会直接告诉你具体是哪个 Bean 写错了，而是把矛头指向 Spring 内部一个叫factoryBeanObjectType的 BeanDefinition 属性——你甚至可能从来没在业务代码里见过它。

这篇文章围绕这个异常，讲清楚它为什么出现、怎么定位、怎么修复，特别适合正在做 Spring Boot 2.x 升 3.x、或者集成了数据库驱动、ORM 扩展框架的开发者参考。先说结论：这不是你业务代码写崩了，而是 Spring 的类型预判机制藏得太深，某些框架又把类型信息塞错了格式。但如果不懂原理，排查时很容易在一个又一个无关线索里绕圈。

1.1 报错通常在启动阶段出现，而且外层还裹着好几层异常

实际抛出来的通常是IllegalStateException，外面再包一层BeanCreationException很常见。日志大概长这样：

ERROR o.s.b.web.embedded.tomcat.TomcatStarter - Error starting Tomcat context. Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'xxxSqlSessionFactory' defined in class path resource ... Caused by: java.lang.IllegalStateException: Invalid value type for attribute 'factoryBeanObjectType': java.lang.String at org.springframework.beans.factory.support.AbstractBeanFactory.getTypeForFactoryBean(AbstractBeanFactory.java) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.getTypeForFactoryBean(...) ...

注意几个关键点：

• 报错在启动阶段就炸，不是等到真的去 getBean 才炸；
• 抛错的 Bean 常常不是你自己定义的，而是第三方框架自动注册出来的；
• Caused by里只写了“类型不对”，没写“值是什么”“哪个 Bean 对不对”，所以很多人第一次看到时，第一反应是去搜自己的代码里有没有 factoryBeanObjectType，结果搜不到。

我建议先把日志往上翻几行，找到最内层的Caused by，这个异常链的头部是分析起点。因为这种问题往往不是顶层业务逻辑导致的，真正的根因藏在内层。

1.2 社区里最常见的高频触发场景

在 Spring Boot 3.x 相关问题的讨论里，这个报错高频率出现在三个场景：

其中前两个占了大多数。数据库驱动的场景里，社区里报得最多的是Spring Boot 3.2.0 + Oracle 数据库驱动的组合：升级后一切正常编译，启动到数据源初始化阶段突然报这个错误。而 MyBatis 系列的问题则集中在版本没跟上 Spring 6，比如项目依赖里还锁着老版本的 mybatis-spring。

这两种场景的解决方向完全不同，一个是升驱动补丁，一个是升 ORM 扩展版本，所以下一步得先搞清楚 Spring 到底为什么会对这个属性这么敏感。

2. factoryBeanObjectType 是干什么的：Spring 为什么只认 Class 不认 String

我第一次见到这个报错的时候也愣住了：factoryBeanObjectType这个名字一看就是 Spring 内部的东西，怎么会被一个字符串污染的？后来去翻了 Spring 的类型推导逻辑才明白，这不是偶发现象，而是 Spring 6 对“FactoryBean 产物类型”这个判断条件做了收紧。

2.1 从 FactoryBean 机制说起：Spring 为什么要提前知道“工厂的产物类型”

普通@Bean方法返回什么类型，Spring 一目了然。但FactoryBean<T>不一样，它是一个工厂，容器里实际放进去的对象是getObject()的返回值，而这个返回值类型和 FactoryBean 自身的类型通常不一样。

举个例子：

public class MyServiceFactoryBean implements FactoryBean<MyService> { @Override public MyService getObject() { return new MyService(); } @Override public Class<?> getObjectType() { return MyService.class; } }

容器里注册的是MyServiceFactoryBean，但你真正想注入给其他 Bean 的是MyService。Spring 在做自动装配、类型匹配、提前校验的时候，需要知道“这个 FactoryBean 最终会产出什么类型”。如果不提前知道，就得把 FactoryBean 先实例化出来，再调getObjectType()，这在很多场景下会提前触发无意义的初始化，代价很高。

于是 Spring 在给 FactoryBean 生成BeanDefinition时，会把目标类型作为factoryBeanObjectType属性临时缓存到 BeanDefinition 里，相当于给流水线上的包裹贴一张“最终品类标签”。拿到标签之后，Spring 不碰工厂就能判断这个 Bean 能被谁消费。

2.2 标签格式要求：Class 或 ResolvableType，而不是纯字符串

校验逻辑很简单，我简化之后核心判断长这样：

Object factoryBeanObjectType = beanDefinition.getAttribute("factoryBeanObjectType"); if (factoryBeanObjectType instanceof ResolvableType) { return ((ResolvableType) factoryBeanObjectType).resolve(); } if (factoryBeanObjectType instanceof Class) { return (Class<?>) factoryBeanObjectType; } throw new IllegalStateException( "Invalid value type for attribute 'factoryBeanObjectType': " + factoryBeanObjectType.getClass().getName() );

当一个框架在构造 BeanDefinition 时，往这个 attribute 里塞了java.lang.String，Spring 的校验分支直接炸了。为什么 Spring 不接受字符串？因为字符串只能表达一个类名，丢失了泛型、嵌套类型等信息；而 Spring 需要的是可以做类型解析的Class或ResolvableType对象。

你可以类比快递分拣：面单上有个“包裹品类代码”区域，分拣机要求必须是数字编码。结果某个发货方的系统往这个区域填了“普通商品”四个字，分拣机识别不了，直接把包裹拦下来了。Spring 这边也一样，第三方框架在注册 BeanDefinition 时用了旧式字符串写法，Spring 6 一严格校验，问题就暴露了。

重点理解：报错信息里java.lang.String指的是当前这个属性值的真实类型，不是期望类型。你搜索关键词时如果能先记住这一点，就不会纠结“String 怎么就不行了”了。

2.3 为什么很多老项目在 Spring 5 时代没事，升到 Spring 6 就炸

Spring 5.3 及更早版本对factoryBeanObjectType的处理更宽容，遇到字符串类型时可能直接返回 null，让后续逻辑再通过其他方式推断类型。Spring 6.0 开始收紧校验，只认 Class 和 ResolvableType，第三方框架只要还在用字符串写内部属性，就会在启动阶段被精准拦截。

所以会出现两个看起来矛盾的现象：

• 同一个第三方库，在 Spring Boot 2.x 下完全正常，升到 Spring Boot 3.x 立刻报错；
• 换一个 Spring 的补丁版本，可能又不报错了，因为后续版本对 String 做了兼容处理，决定“先宽容，让 getObjectType 再去兜底”。

这也解释了为什么有人升级一个小版本后问题自然消失，有人怎么升级都不行——取决于你用的是哪个框架、框架在哪个版本适配了 Spring 6 的规则。接下来看最常见的两种根因。

3. 最常见的两个根因：数据库驱动自动配置与老版本 ORM 扩展

把原理理清楚之后，再看具体场景就顺了。我排查这类报错时，遇到最多的是两种情况。

3.1 场景一：Spring Boot 3.2.0 与数据库驱动的自动配置冲突

这个报错在社区里出现频率最高的一组组合是Spring Boot 3.2.0 + Oracle 数据库驱动。现象非常一致：项目刚升级到 Spring Boot 3.2.0，数据源配置看起来什么都没改，启动时却在数据源初始化阶段抛出这个异常，随后是整个应用启动失败。

问题出在自动配置链路上：Spring Boot 3.2 对数据源创建机制做了调整，驱动依赖包里提供的数据源创建工厂在向 Spring 暴露类型信息时，把类名以字符串形式固化进了factoryBeanObjectType属性。Spring 6 一检查发现“这标签格式不对”，直接拒绝继续执行。这种问题不是你的application.yml写错，也不是连接串有问题，纯粹是自动配置代码和 Spring 6 的校验逻辑撞上了。

如果你的版本正好卡在这种组合上，最快验证方式是临时把 Spring Boot 版本升到当前 3.2.x 的最新补丁版，或者直接用 3.3+。这类兼容性问题在升级补丁后基本都会消失。如果你暂时不能升级版本，可以用 Chapter 5 里的“显式定义 Bean”方案绕开自动配置。

3.2 场景二：老版本 MyBatis-Spring 与 Spring 6 的类型推断冲突

第二个高频来源是 MyBatis 系列。SqlSessionFactoryBean本身实现了FactoryBean<SqlSessionFactory>，所以它会经历上面说的类型预判流程。如果在 Spring Boot 3 项目里还锁着老的mybatis-spring-boot-starter2.x，或者依赖树里混入了mybatis-spring2.0/2.1 这种为 Spring 5 准备的版本，启动时极容易在这个环节报错。

这个问题的本质是：老版本 mybatis-spring 在注册 SqlSessionFactoryBean 时，按照 Spring 5 时代的内部约定塞了类型信息，Spring 6 不认识，于是炸给你看。

解决方向非常明确：升级到适配 Spring 6 的版本线。

先检查你自己的依赖树，Maven 项目执行：

mvn dependency:tree -Dincludes=org.mybatis

Gradle 项目执行：

./gradlew dependencyInsight --dependency org.mybatis

重点看两个坐标：

• org.mybatis.spring.boot:mybatis-spring-boot-starter：Spring Boot 3 项目要确保使用 3.0.x；
• org.mybatis:mybatis-spring：要确保使用 3.0.x 及以上。

顺带说一句，很多老项目不是直接引的 mybatis-spring，而是被某个二次封装组件带进来的。所以光改自己 pom 里的 starter 版本没用，要看整棵依赖树里有没有冲突坐标，必要时用exclusion排除掉旧版本。

4. 五分钟定位到具体是哪个 Bean 在作妖

知道了常见场景还不够，真正值钱的是定位手段。因为报错信息不会手把手告诉你“我就是 mybatis 的 SqlSessionFactoryBean 干的”，你需要在项目里快速确认是谁的factoryBeanObjectType被写成了字符串。

4.1 第一步：先看内层异常和 Bean 名称

把日志向上翻，找Caused by之前那一长串BeanCreationException的文本，里面通常会包含一个 bean 名称。比如：

Error creating bean with name 'xxxSqlSessionFactory' defined in class path resource ...

这个名称就是我定位的第一线索。如果异常链里没有名称，就说明某个第三方框架在更早期的容器刷选阶段就挂了，需要走下面的动态扫描法。

4.2 第二步：用 BeanFactoryPostProcessor 扫描所有 BeanDefinition

写一个一次性BeanFactoryPostProcessor，把容器里所有factoryBeanObjectType属性值类型为 String 的 BeanDefinition 全打印出来，比对着日志猜快得多。

import org.springframework.beans.BeansException; import org.springframework.beans.factory.config.BeanFactoryPostProcessor; import org.springframework.beans.factory.config.ConfigurableListableBeanFactory; import org.springframework.beans.factory.support.BeanDefinitionRegistry; public class FactoryBeanObjectTypeScanner implements BeanFactoryPostProcessor { @Override public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException { if (!(beanFactory instanceof BeanDefinitionRegistry registry)) { return; } for (String beanName : registry.getBeanDefinitionNames()) { var bd = registry.getBeanDefinition(beanName); Object attr = bd.getAttribute("factoryBeanObjectType"); if (attr != null) { System.out.printf( "scan: bean=%s, attrType=%s, attrValue=%s%n", beanName, attr.getClass().getName(), attr ); } } } }

把它注册成普通@Bean就能临时跑起来：

@Bean public static BeanFactoryPostProcessor factoryBeanObjectTypeScanner() { return new FactoryBeanObjectTypeScanner(); }

建议不要直接用System.out而是用你项目的日志框架打warn级别，方便在日志文件里搜scan关键字。扫描输出里，凡是attrType=java.lang.String的那一行，基本就是出问题的 BeanDefinition。

4.3 第三步：根据 Bean 名称反查来源

拿到可疑 Bean 名称后，接着在 IDE 里搜索这个名字，或者看它的类名前缀是哪个包。比如扫描结果里出现mybatisSqlSessionFactory，明显是 MyBatis 的注册逻辑；如果出现xxxDataSourceFactory，则是数据库自动配置链路。判断来源后，你就能知道该升级框架版本、改配置，还是走手动覆盖这条路。

踩过几次之后，我自己的定位顺序固定成：先看异常文本里的 bean 名，再看依赖树版本，最后再用扫描器兜底。三步都用不上 5 分钟，比反复启动项目试日志高效得多。

5. 三板斧修复：按性价比从高到低排列

定位到原因之后，修复方案可以按照“改动量小、效果直接”的顺序来。

5.1 第一板斧：升级框架版本，从根上消除脏属性

如果确认是数据库驱动的自动配置问题，优先升级 Spring Boot 补丁版本，或者升级数据库驱动本身。如果确认是 MyBatis 扩展问题，优先升mybatis-spring-boot-starter到 3.0.x、mybatis-spring到 3.0.x。

升级前用依赖树命令确认没有旧版本残留：

mvn dependency:tree -Dincludes=org.mybatis,com.oracle.database.jdbc

这一步看起来简单，却是治本率最高的一招。因为很多第三方框架产生脏属性的根源，就是内部还在用旧 Spring 时代的 BeanDefinition 写法，你从应用层面怎么绕都绕不彻底。

5.2 第二板斧：显式定义 Bean，绕开自动配置陷阱

如果项目暂时不能升版本，另一个立竿见影的办法是手动声明关键 Bean，让自动配置因为@ConditionalOnMissingBean条件不满足而直接退场。

以数据库数据源为例：

@Configuration public class DataSourceConfig { @Bean public DataSource dataSource() { HikariConfig config = new HikariConfig(); config.setJdbcUrl(jdbcUrl); config.setUsername(username); config.setPassword(password); config.setDriverClassName(driverClassName); return new HikariDataSource(config); } }

当容器里已经存在DataSource类型的 Bean 时，Spring Boot 的 DataSource 自动配置不会再触发，从而跳过那段读取脏属性的逻辑。这个方案能快速止血，代价是你得自己管理数据源配置，适合应急，不适合长期依赖。

同理，如果问题出在某个第三方自动配置类上，你可以查一下它的条件注解有没有手动关掉的方式，比如：

spring.autoconfigure.exclude=com.xxx.autoconfigure.YyyAutoConfiguration

不过我不建议一上来就大面积排除自动配置，容易引发连锁缺失。

5.3 第三板斧：程序化清洗 BeanDefinition 的字符串属性

如果前面两招都行不通，再祭出终极大招：写一个 BeanFactoryPostProcessor，启动阶段扫描全容器，把类型为 String 的factoryBeanObjectType要么转成真正的Class，要么先清掉让它走后续的 getObjectType 兜底。

import org.springframework.beans.BeansException; import org.springframework.beans.factory.config.BeanFactoryPostProcessor; import org.springframework.beans.factory.config.ConfigurableListableBeanFactory; import org.springframework.beans.factory.support.BeanDefinitionRegistry; import org.springframework.util.ClassUtils; public class FactoryBeanObjectTypeFixer implements BeanFactoryPostProcessor { @Override public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException { if (!(beanFactory instanceof BeanDefinitionRegistry registry)) { return; } for (String beanName : registry.getBeanDefinitionNames()) { var bd = registry.getBeanDefinition(beanName); Object attr = bd.getAttribute("factoryBeanObjectType"); if (attr instanceof String className && !className.isBlank()) { try { Class<?> clazz = ClassUtils.forName(className, getClass().getClassLoader()); bd.setAttribute("factoryBeanObjectType", clazz); } catch (ClassNotFoundException e) { // 类名无法加载时，直接移除该属性，交给 FactoryBean.getObjectType 兜底 bd.setAttribute("factoryBeanObjectType", null); } } } } }

使用时注册为静态 Bean：

@Bean public static BeanFactoryPostProcessor fixFactoryBeanObjectType() { return new FactoryBeanObjectTypeFixer(); }

这个方法我实际测下来，对大多数第三方注册的 BeanDefinition 都有效。注意两点：

• 方法必须是static，否则 Spring 会在初始化阶段提前碰这个配置类，反而制造新的问题；
• 如果类名能加载，优先转成Class再写回去，这样既保留类型信息，又满足 Spring 6 的校验；
• 如果类名加载失败，直接置 null 也安全，因为 Spring 后面还有一层getObjectType()兜底。

不过要说明白：这属于“打补丁”式修复，治标不治本。它能帮你把服务拉起来，但第三方框架本身不升级，后续遇到更严格校验时可能还会暴露其他内部属性问题。所以这个方案适合“先恢复业务运行，再排期升级”的场景。

6. 还有一类根因是“自己人”：自定义 FactoryBean 时把内部属性搞脏了

很多文章都说这是框架兼容性问题，但实际上还有一部分人，是自己在写自定义 FactoryBean 或扩展框架时，无意中把factoryBeanObjectType写成了字符串。这类问题排查起来更费劲，因为代码就在自己手里，却总想不到是这里。

6.1 自定义 FactoryBean 的正确姿势

标准写法就三步：实现FactoryBean<T>，覆盖getObjectType()，按需覆盖isSingleton()。

public class MyServiceFactoryBean implements FactoryBean<MyService> { private final MyService myService = new MyService(); @Override public MyService getObject() { return myService; } @Override public Class<?> getObjectType() { return MyService.class; } @Override public boolean isSingleton() { return true; } }

如果你用@Bean注册它，Spring 会在容器启动时调用getObjectType()自动把类型信息缓存进 BeanDefinition。你甚至不需要手动碰factoryBeanObjectType属性。

6.2 使用 BeanDefinitionBuilder 时别踩内部属性的坑

更隐蔽的情况是，代码里通过BeanDefinitionBuilder手动注册 Bean：

BeanDefinitionBuilder builder = BeanDefinitionBuilder .genericBeanDefinition(MyServiceFactoryBean.class) .addPropertyValue("someProp", "someValue"); // 错误示范：直接把类名字符串塞进内部属性 builder.getBeanDefinition().setAttribute("factoryBeanObjectType", "com.example.MyService"); // 正确示范：要么不设置，要么直接设置 Class 对象 builder.getBeanDefinition().setAttribute("factoryBeanObjectType", MyService.class);

这两种写法在 Spring Boot 2.x 下可能都能跑，但在 Spring 6 下，第一种必然触发Invalid value type for attribute 'factoryBeanObjectType': java.lang.String。如果你负责维护内部框架或公共组件，搜索代码里是否有类似setAttribute("factoryBeanObjectType", "...")的调用，很可能问题就在这里。

另外，XML 和 Groovy 配置里如果出现<constructor-arg>之类传字符串的场景，也要多留个心眼。Spring 的 XML 属性天然是字符串，把内部属性塞进去时最容易发生类型错配。原则很简单：这是 Spring 的内部属性，不到万不得已，不要手动改；真需要改，就传 Class 对象。

6.3 这条“内部属性红线”也是升级检查单的一项

现在我评估一个项目能不能平滑升级到 Spring Boot 3 时，除了看依赖版本，还会特意搜一下代码和公司内部组件里有没有直接引用factoryBeanObjectType这类 Spring 内部属性名的代码。凡是引用了，升级前都要重新审视一遍，因为 Spring 6 对内部约定的校验力度明显加强了，不只是这一处属性，类似的内部字段都可能因为类型格式不达标而启动失败。

如果你正在维护公共 Starter，我强烈建议把“内部属性一律传 Class，绝不传字符串”写进代码规范。这看起来是一个毫不起眼的细节，但碰上 Spring 6 之后，它就是妥妥的生产事故触发器。