从一次ClassNotFoundException看大模型的技术分析可靠性升级JDK 21 Spring Boot 3.3.5时遇到springdoc报错两个AI模型给出了截然相反的根因分析——一个说类被移除了一个说类还没出生。事实到底是什么大模型为什么会在确定性的技术事实上翻车背景在将项目从JDK 8 Spring Boot 2.0升级到JDK 21 Spring Boot 3.3.5的过程中启动时遇到了如下报错java.lang.IllegalStateException: Error processing condition on org.springdoc.webmvc.ui.SwaggerConfig.springWebProvider Caused by: java.lang.NoClassDefFoundError: org/springframework/web/servlet/resource/LiteWebJarsResourceResolver Caused by: java.lang.ClassNotFoundException: org.springframework.web.servlet.resource.LiteWebJarsResourceResolver环境信息JDK 21Spring Boot 3.3.5springdoc-openapi-starter-webmvc-ui 2.6.0两次AI分析两个截然相反的结论通义灵码的分析这个错误是因为Spring Boot 3.x已经移除了LiteWebJarsResourceResolver类。这个类在Spring Boot 2.x中用于处理WebJars资源但在Spring Boot 3.x中已被移除。给出的解决方案是移除webjars相关配置、修改拦截器、添加spring.web.resources.add-mappingstrue。按提示操作后报错依然存在。扣子的分析LiteWebJarsResourceResolver不是被移除了而是Spring Framework 6.2才新增的类Spring Boot 3.3.5对应的Spring Framework 6.1.14没有这个类。问题根源还是springdoc版本。给出的排查步骤mvn dependency:tree -Dincludesorg.springdoc确认实际解析版本清理本地Maven缓存后重新编译如果确认是2.6.0仍报错降到2.5.0将springdoc降到2.5.0后问题解决。事实到底是什么查Spring Framework的源码和Javadoc时间线很清晰版本是否包含LiteWebJarsResourceResolverSpring Framework 5.x对应Boot 2.x❌ 不存在Spring Framework 6.1.x对应Boot 3.3.x❌ 不存在Spring Framework 6.2.x对应Boot 3.4.x✅ 新增所以扣子是对的通义灵码是错的。LiteWebJarsResourceResolver从来就不存在于Spring Boot 2.x时代它是Spring Framework 6.2才新增的类。springdoc 2.6.0开始引用了这个新类但Spring Boot 3.3.x的Spring Framework版本还停留在6.1.x所以出现了ClassNotFoundException。通义灵码说的2.x有、3.x移除了完全是无中生有。大模型为什么会翻车Spring的版本变更记录是公开的、确定的事实哪个版本有哪个类应该是清晰可查的。那为什么模型还会搞错1. 模型不是查文档是在回忆训练数据模型没有实时查API文档的能力它靠训练时见过的信息来推断。对于讨论充分的API变更比如javax→jakarta的包名迁移训练数据里大量讨论模型能答对。但LiteWebJarsResourceResolver是一个非常冷门的类网上几乎没人讨论过模型没见过相关信息只能靠推理。2. 遇到不确定时模型会合理推测而不是承认不知道通义灵码看到报错链路是SwaggerConfig → LiteWebJarsResourceResolver → ClassNotFoundException又知道从Boot 2.x升到3.x就直接推理出2.x有3.x移除了——听起来合理但事实恰好相反。正确的分析——“这个类是6.2新增的你的Boot版本对应的Framework不够新”——需要一个非常具体的知识点。而错误的分析——“3.x移除了2.x的类”——符合升级后找不到类的一般直觉模型倾向于选择这种能解释现象的答案。3. 模型倾向于给出有解释力的答案而非正确的答案两个答案都能解释为什么找不到类但方向完全相反。模型在缺乏确切知识时会优先选择逻辑上自洽的解释而不是停下来承认我不确定。正确的排查方式遇到框架类的ClassNotFoundException直接查证比问模型靠谱得多# 查看实际解析的依赖版本mvn dependency:tree-Dincludesorg.springdoc# 直接搜本地仓库中是否存在目标类find~/.m2/repository/org/springframework-nameLiteWebJarsResourceResolver.class或者直接查Spring官方Javadoc搜索类名看since标注LiteWebJarsResourceResolver— since 6.2一行注释胜过千言万语。最终解决方案将springdoc-openapi版本从2.6.0降到2.5.0springdoc.version2.5.0/springdoc.version2.5.0不依赖Spring Framework 6.2的类与Spring Boot 3.3.x完美兼容。反思这件事给我一个深刻教训大模型对冷门API变更的事实判断不可靠越是解释得通的结论越要警惕。大模型擅长的是代码生成、逻辑推理、方案设计这些需要综合能力的场景。但在某个类的引入版本号是多少这种确定性事实面前它本质上是在猜——猜对了是你运气好猜错了你就要踩坑。下次遇到类似问题先查官方文档和源码再让模型帮你分析。模型是工具不是百科全书。
从一次ClassNotFoundException看大模型的技术分析可靠性
发布时间：2026/6/3 8:26:01
从一次ClassNotFoundException看大模型的技术分析可靠性升级JDK 21 Spring Boot 3.3.5时遇到springdoc报错两个AI模型给出了截然相反的根因分析——一个说类被移除了一个说类还没出生。事实到底是什么大模型为什么会在确定性的技术事实上翻车背景在将项目从JDK 8 Spring Boot 2.0升级到JDK 21 Spring Boot 3.3.5的过程中启动时遇到了如下报错java.lang.IllegalStateException: Error processing condition on org.springdoc.webmvc.ui.SwaggerConfig.springWebProvider Caused by: java.lang.NoClassDefFoundError: org/springframework/web/servlet/resource/LiteWebJarsResourceResolver Caused by: java.lang.ClassNotFoundException: org.springframework.web.servlet.resource.LiteWebJarsResourceResolver环境信息JDK 21Spring Boot 3.3.5springdoc-openapi-starter-webmvc-ui 2.6.0两次AI分析两个截然相反的结论通义灵码的分析这个错误是因为Spring Boot 3.x已经移除了LiteWebJarsResourceResolver类。这个类在Spring Boot 2.x中用于处理WebJars资源但在Spring Boot 3.x中已被移除。给出的解决方案是移除webjars相关配置、修改拦截器、添加spring.web.resources.add-mappingstrue。按提示操作后报错依然存在。扣子的分析LiteWebJarsResourceResolver不是被移除了而是Spring Framework 6.2才新增的类Spring Boot 3.3.5对应的Spring Framework 6.1.14没有这个类。问题根源还是springdoc版本。给出的排查步骤mvn dependency:tree -Dincludesorg.springdoc确认实际解析版本清理本地Maven缓存后重新编译如果确认是2.6.0仍报错降到2.5.0将springdoc降到2.5.0后问题解决。事实到底是什么查Spring Framework的源码和Javadoc时间线很清晰版本是否包含LiteWebJarsResourceResolverSpring Framework 5.x对应Boot 2.x❌ 不存在Spring Framework 6.1.x对应Boot 3.3.x❌ 不存在Spring Framework 6.2.x对应Boot 3.4.x✅ 新增所以扣子是对的通义灵码是错的。LiteWebJarsResourceResolver从来就不存在于Spring Boot 2.x时代它是Spring Framework 6.2才新增的类。springdoc 2.6.0开始引用了这个新类但Spring Boot 3.3.x的Spring Framework版本还停留在6.1.x所以出现了ClassNotFoundException。通义灵码说的2.x有、3.x移除了完全是无中生有。大模型为什么会翻车Spring的版本变更记录是公开的、确定的事实哪个版本有哪个类应该是清晰可查的。那为什么模型还会搞错1. 模型不是查文档是在回忆训练数据模型没有实时查API文档的能力它靠训练时见过的信息来推断。对于讨论充分的API变更比如javax→jakarta的包名迁移训练数据里大量讨论模型能答对。但LiteWebJarsResourceResolver是一个非常冷门的类网上几乎没人讨论过模型没见过相关信息只能靠推理。2. 遇到不确定时模型会合理推测而不是承认不知道通义灵码看到报错链路是SwaggerConfig → LiteWebJarsResourceResolver → ClassNotFoundException又知道从Boot 2.x升到3.x就直接推理出2.x有3.x移除了——听起来合理但事实恰好相反。正确的分析——“这个类是6.2新增的你的Boot版本对应的Framework不够新”——需要一个非常具体的知识点。而错误的分析——“3.x移除了2.x的类”——符合升级后找不到类的一般直觉模型倾向于选择这种能解释现象的答案。3. 模型倾向于给出有解释力的答案而非正确的答案两个答案都能解释为什么找不到类但方向完全相反。模型在缺乏确切知识时会优先选择逻辑上自洽的解释而不是停下来承认我不确定。正确的排查方式遇到框架类的ClassNotFoundException直接查证比问模型靠谱得多# 查看实际解析的依赖版本mvn dependency:tree-Dincludesorg.springdoc# 直接搜本地仓库中是否存在目标类find~/.m2/repository/org/springframework-nameLiteWebJarsResourceResolver.class或者直接查Spring官方Javadoc搜索类名看since标注LiteWebJarsResourceResolver— since 6.2一行注释胜过千言万语。最终解决方案将springdoc-openapi版本从2.6.0降到2.5.0springdoc.version2.5.0/springdoc.version2.5.0不依赖Spring Framework 6.2的类与Spring Boot 3.3.x完美兼容。反思这件事给我一个深刻教训大模型对冷门API变更的事实判断不可靠越是解释得通的结论越要警惕。大模型擅长的是代码生成、逻辑推理、方案设计这些需要综合能力的场景。但在某个类的引入版本号是多少这种确定性事实面前它本质上是在猜——猜对了是你运气好猜错了你就要踩坑。下次遇到类似问题先查官方文档和源码再让模型帮你分析。模型是工具不是百科全书。
