1. 项目概述一次由Maven依赖升级引发的“薛定谔”异常最近在维护一个老项目时碰到了一个典型的“开发环境正常生产环境爆炸”的诡异问题。项目原本使用的是fastjson 1.2.83由于众所周知的安全漏洞问题团队决定将其升级到fastjson2。在IDEA里代码跑得风生水起所有单元测试都绿灯通过。然而当我们信心满满地执行mvn clean package打出jar包部署到线上环境后应用启动就直接抛出了ClassNotFoundException或者NoSuchMethodError矛头直指fastjson相关的类。第一反应是依赖没打进去检查jar包fastjson2的库明明安安稳稳地躺在BOOT-INF/lib/下面。这就奇了怪了为什么IDEA能跑jar包就跑不了经过一番排查根源竟然藏在pom.xml的一个角落里某个间接依赖或者Maven的依赖管理dependencyManagement部分悄无声息地把fastjson的版本又给“拉”回来了。这种问题在大型项目、多模块项目或者接手历史包袱时尤其常见。它不是简单的依赖冲突而是一种“依赖版本覆盖”导致的运行时类加载错乱。开发环境IDEA的类路径Classpath构建逻辑与打包后jar包内的类路径逻辑存在差异使得问题在开发阶段被完美隐藏。这篇文章我就来彻底拆解这个问题的来龙去脉分享从定位、分析到根治的完整实操流程以及如何建立防线避免再次踩坑。2. 问题根因深度剖析Maven依赖决议的“暗箱操作”要解决问题必须先理解问题背后的机制。为什么IDEA和打包后的行为会不一致核心在于Maven的依赖决议机制和不同环境下的类路径构成。2.1 Maven依赖决议与“最近定义优先”原则Maven在构建项目时会解析所有直接和间接依赖形成一个依赖树。当出现同一个依赖的不同版本例如fastjson的1.2.83和2.0.xx时它需要决定最终使用哪一个。这里的关键规则是“最近定义优先”。“定义”的层级从当前项目的pom.xml开始到父POM再到引入的第三方依赖的POM。“近”的含义在依赖树中路径短的优先。但更常见且重要的是在pom.xml文件中显式声明的版本其优先级高于间接传递进来的版本。问题往往出在这里你以为你在顶层pom.xml的 里统一指定了fastjson2的版本但某个“深藏不露”的依赖或者某个子模块又直接声明了fastjson:1.2.83。根据“最近定义优先”这个“更近”的1.2.83版本会覆盖掉你全局管理的2.0.xx版本。2.2 IDEA与打包Jar的类路径差异这是导致“薛定谔”异常的直接原因。IDEA开发环境IDEA在构建项目模块的类路径时通常非常“智能”和“完整”。它会收集所有模块的依赖并基于Maven的依赖树和自身的索引构建一个类路径。关键点在于IDEA有时会“看到”并包含多个版本的jar包但它默认的类加载顺序可能恰好让你调用的版本比如fastjson2先被加载从而掩盖了冲突。你可以通过IDEA的mvn dependency:tree输出看到冲突但运行时却正常。打包后的Fat Jar以Spring Boot为例当我们使用spring-boot-maven-plugin打出一个可执行的、包含所有依赖的Fat Jar时它的类路径构建是严格且扁平的。插件会解析最终的依赖树对于同一个groupId:artifactId只会选取一个版本即Maven决议后的最终版本打入BOOT-INF/lib/。如果Maven决议错误地选择了旧版本1.2.83那么jar包里就只有1.2.83你的代码在运行时调用fastjson2的API自然就会找不到类。一个典型的错误场景项目父POM的 中声明fastjson2.version2.0.48。项目显式依赖com.alibaba.fastjson2:fastjson2:${fastjson2.version}。但是项目同时依赖了另一个第三方库com.some:old-library:1.0而这个old-library在自己的pom.xml中直接声明了依赖com.alibaba:fastjson:1.2.83。此时Maven依赖树中同时存在com.alibaba.fastjson2:fastjson2:2.0.48和com.alibaba:fastjson:1.2.83。它们是两个不同的ArtifactId(fastjson2vsfastjson)所以不会发生版本覆盖。致命陷阱你的代码中可能历史遗留原因部分类导入的仍然是import com.alibaba.fastjson.JSON;。在IDEA中由于两个jar包都在类路径里编译器能通过。但在打包时如果old-library的传递依赖被保留那么fastjson-1.2.83.jar会被打入包中。运行时JVM加载了com.alibaba.fastjson.JSON这个类来自1.2.83但它内部实现与fastjson2不兼容或者你代码中某些方法调用在新旧版本间有差异就会引发NoSuchMethodError或ClassCastException等运行时错误。注意fastjson和fastjson2的groupId和artifactId都不同它们是两个独立的库。因此问题不仅仅是版本冲突更多是“错误地引入了本应被替换的旧库”。3. 诊断与排查实战揪出隐藏的依赖元凶当遇到此类问题不要盲目猜测系统化的排查是最高效的。以下是 step-by-step 的诊断流程。3.1 第一步在项目根目录执行依赖树分析打开终端进入你的项目根目录包含pom.xml的目录执行命令mvn dependency:tree -Dverbose dependency_tree.txt-Dverbose参数至关重要它会显示所有冲突和被忽略的依赖。然后用文本编辑器打开生成的dependency_tree.txt文件。搜索关键信息搜索com.alibaba:fastjson查看是否还有1.2.x版本的依赖存在以及它是通过哪个路径传递进来的。你会看到类似下面的输出[INFO] - com.some:old-library:jar:1.0:compile [INFO] | \- com.alibaba:fastjson:jar:1.2.83:compile这就明确指出了罪魁祸首是old-library。搜索com.alibaba.fastjson2确认你期望的fastjson2版本是否在依赖树中以及它的路径。注意omitted for conflict with提示verbose模式会显示因为版本冲突而被忽略的依赖。如果看到fastjson2的某个版本被忽略说明有更“近”的声明覆盖了它你需要找到那个声明。3.2 第二步检查Maven的依赖管理部分查看项目顶层pom.xml以及所有父POM的 部分。确认fastjson2的版本是否在此处被正确定义。同时也要检查是否有其他地方比如某个profile或属性文件意外地覆盖了这个版本属性。3.3 第三步使用IDEA内置工具交叉验证IDEA提供了图形化的依赖分析工具非常直观。在IDEA中打开你的pom.xml文件。右键点击文件内容选择Maven - Show Dependencies。这会打开一个依赖图。在左上角的搜索框中输入fastjson。图表会高亮显示所有相关的依赖。你可以看到红色实线表示依赖关系。红色虚线通常表示存在版本冲突或排除。你可以点击某个库查看哪些模块依赖了它。通过这个图可以快速定位是哪个模块引入了不需要的fastjson。3.4 第四步对比打包前后的依赖有时候依赖树显示一切正常但打包结果不对。这可能和打包插件如spring-boot-maven-plugin的配置有关。解压你生成的jar包例如your-app.jar。jar -xf your-app.jar # 或者使用解压软件直接打开查看 BOOT-INF/lib/ 目录查看BOOT-INF/lib/目录下是否存在fastjson-1.2.83.jar和fastjson2-2.0.48.jar。如果两者都存在那问题就是运行时类加载顺序或代码兼容性问题。如果只有fastjson-1.2.83.jar那说明Maven决议或插件配置有问题fastjson2根本没被打进去。4. 解决方案与实操彻底清理旧依赖找到问题根源后我们有几种武器来消灭它。4.1 方案一在依赖声明中直接排除最常用对于那个引入了旧版fastjson的第三方依赖例如com.some:old-library我们在声明对其的依赖时直接排除掉传递进来的fastjson。dependency groupIdcom.some/groupId artifactIdold-library/artifactId version1.0/version exclusions exclusion groupIdcom.alibaba/groupId artifactIdfastjson/artifactId /exclusion /exclusions /dependency实操要点修改后务必再次执行mvn dependency:tree确认com.alibaba:fastjson已经从依赖树中消失。确保你的项目代码中已经完全移除了对com.alibaba.fastjson包下所有类的引用如JSON,JSONObject,JSONArray全部替换为com.alibaba.fastjson2的对应类。可以使用IDEA的全局搜索CtrlShiftF来检查。4.2 方案二在依赖管理中强制统一版本适用于多模块如果你的项目是一个多模块项目并且有多个模块可能间接引入fastjson可以在父POM的 中强制指定com.alibaba:fastjson的版本为一个空版本99.0-does-not-exist或者一个极高的无效版本从而让所有模块都无法引入它。dependencyManagement dependencies !-- 其他依赖管理 -- !-- 禁止引入 fastjson 1.x -- dependency groupIdcom.alibaba/groupId artifactIdfastjson/artifactId version99.0-does-not-exist/version /dependency !-- 正确定义 fastjson2 的版本 -- dependency groupIdcom.alibaba.fastjson2/groupId artifactIdfastjson2/artifactId version2.0.48/version /dependency /dependencies /dependencyManagement注意事项这种方法比较“暴力”可能会破坏那些真正需要fastjson 1.x且与fastjson2不兼容的依赖尽管这种情况在升级后应尽量避免。使用前需充分测试。4.3 方案三使用Maven Enforcer插件主动防御这是一种更工程化的预防措施。maven-enforcer-plugin可以定义规则在构建阶段就禁止引入特定的依赖。build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-enforcer-plugin/artifactId version3.4.1/version executions execution idenforce-banned-dependencies/id goals goalenforce/goal /goals configuration rules bannedDependencies excludes !-- 禁止任何版本的 fastjson 1.x -- excludecom.alibaba:fastjson:[,2.0)/exclude !-- 你也可以只禁止特定的危险版本如存在漏洞的版本 -- !-- excludecom.alibaba:fastjson:[1.2.24,1.2.83]/exclude -- /excludes /bannedDependencies /rules failtrue/fail /configuration /execution /executions /plugin /plugins /build配置此插件后如果任何依赖试图引入fastjson1.x版本Maven构建将会直接失败并给出明确的错误信息从而在CI/CD流程中就阻断问题而不是等到运行时才发现。4.4 方案四检查并配置打包插件确保你的spring-boot-maven-plugin或其它打包插件没有特殊的依赖处理规则。通常默认配置即可但如果你有自定义的或配置需要检查是否无意中过滤或包含了特定依赖。5. 完整升级与验证清单为了避免遗漏这里提供一个从fastjson升级到fastjson2的完整检查清单。更新依赖声明在pom.xml中将com.alibaba:fastjson依赖移除或注释掉。添加com.alibaba.fastjson2:fastjson2依赖。在 中统一管理版本推荐。全局代码替换包导入将所有import com.alibaba.fastjson.XXX替换为import com.alibaba.fastjson2.XXX。类名通常JSON,JSONObject,JSONArray,TypeReference等核心类名不变但包路径变了。注意JSONPath等类可能在fastjson2中有单独的模块。API变更fastjson2并非100%兼容。需要重点检查序列化/反序列化方法如parseObject的某些重载。Feature枚举常量有些可能已被弃用或改名如SerializerFeature,ParserFeature在fastjson2中合并或调整了。自定义序列化器/反序列化器可能需要适配新的接口。处理传递依赖使用mvn dependency:tree找出所有传递引入的com.alibaba:fastjson。在相应的依赖声明中添加 。构建与打包验证执行mvn clean compile确保编译通过。执行mvn dependency:tree确认依赖树干净无旧版fastjson。执行mvn clean package打包。解压或查看生成的jar/war包确认lib目录下只有fastjson2的jar包没有fastjson-1.x.x.jar。运行时验证在本地运行打包后的应用进行核心功能测试。特别测试涉及JSON序列化/反序列化的所有边界场景和复杂对象。6. 常见问题与避坑指南Q1排除了旧依赖后编译报错找不到fastjson的类A1这恰恰证明你的代码中还有地方在引用旧的com.alibaba.fastjson包。需要完成上述“全局代码替换”的步骤。IDEA的“Optimize Imports”功能可以帮助快速清理无用的import语句。Q2使用了排除但打包后旧版本的jar依然存在A2可能有多个不同的依赖都引入了fastjson你只排除了其中一个。再次检查完整的依赖树。也可能是打包插件如maven-shade-plugin的配置问题检查是否有将依赖重定位relocate或特殊包含的配置。Q3升级到fastjson2后序列化的日期格式、空值处理等行为和之前不一致A3这是API行为变更不是bug。fastjson2为了性能和安全性对一些默认行为做了调整。你需要仔细阅读fastjson2的官方文档或迁移指南查看JSONWriter.Feature和JSONReader.Feature等配置项并在代码中显式配置你需要的序列化/反序列化特性。Q4第三方库强制依赖fastjson 1.x且无法排除否则会导致该库功能异常怎么办A4这是最棘手的情况。可以考虑以下方案联系该库的维护者请求其升级支持或提供不依赖fastjson的版本。寻找替代库。如果必须共存确保你的业务代码只使用fastjson2。对于那个第三方库尝试通过Maven的 将其依赖的fastjson升级到一个与fastjson2包名不冲突的、较新的、漏洞已修复的1.2.x版本如1.2.84但这需要充分测试兼容性因为fastjson2和fastjson 1.x的类加载器可能会同时加载两个不同的com.alibaba.fastjson.JSON类引发难以预料的错误。强烈不推荐此方案应作为最后不得已的临时手段。个人心得这类依赖冲突问题最好的解决时机是在项目架构设计之初就建立规范。例如在父POM中通过 严格管控所有常用组件的版本使用maven-enforcer-plugin设置禁令在CI流水线中加入依赖检查步骤。对于历史项目每次升级核心组件如JSON库、日志门面、数据库驱动等时把“依赖树分析”作为规定动作防患于未然。这次从fastjson到fastjson2的升级不仅仅是一个jar包的替换更是一次对项目依赖治理能力的检验。
1. 项目概述一次由Maven依赖升级引发的“薛定谔”异常最近在维护一个老项目时碰到了一个典型的“开发环境正常生产环境爆炸”的诡异问题。项目原本使用的是fastjson 1.2.83由于众所周知的安全漏洞问题团队决定将其升级到fastjson2。在IDEA里代码跑得风生水起所有单元测试都绿灯通过。然而当我们信心满满地执行mvn clean package打出jar包部署到线上环境后应用启动就直接抛出了ClassNotFoundException或者NoSuchMethodError矛头直指fastjson相关的类。第一反应是依赖没打进去检查jar包fastjson2的库明明安安稳稳地躺在BOOT-INF/lib/下面。这就奇了怪了为什么IDEA能跑jar包就跑不了经过一番排查根源竟然藏在pom.xml的一个角落里某个间接依赖或者Maven的依赖管理dependencyManagement部分悄无声息地把fastjson的版本又给“拉”回来了。这种问题在大型项目、多模块项目或者接手历史包袱时尤其常见。它不是简单的依赖冲突而是一种“依赖版本覆盖”导致的运行时类加载错乱。开发环境IDEA的类路径Classpath构建逻辑与打包后jar包内的类路径逻辑存在差异使得问题在开发阶段被完美隐藏。这篇文章我就来彻底拆解这个问题的来龙去脉分享从定位、分析到根治的完整实操流程以及如何建立防线避免再次踩坑。2. 问题根因深度剖析Maven依赖决议的“暗箱操作”要解决问题必须先理解问题背后的机制。为什么IDEA和打包后的行为会不一致核心在于Maven的依赖决议机制和不同环境下的类路径构成。2.1 Maven依赖决议与“最近定义优先”原则Maven在构建项目时会解析所有直接和间接依赖形成一个依赖树。当出现同一个依赖的不同版本例如fastjson的1.2.83和2.0.xx时它需要决定最终使用哪一个。这里的关键规则是“最近定义优先”。“定义”的层级从当前项目的pom.xml开始到父POM再到引入的第三方依赖的POM。“近”的含义在依赖树中路径短的优先。但更常见且重要的是在pom.xml文件中显式声明的版本其优先级高于间接传递进来的版本。问题往往出在这里你以为你在顶层pom.xml的 里统一指定了fastjson2的版本但某个“深藏不露”的依赖或者某个子模块又直接声明了fastjson:1.2.83。根据“最近定义优先”这个“更近”的1.2.83版本会覆盖掉你全局管理的2.0.xx版本。2.2 IDEA与打包Jar的类路径差异这是导致“薛定谔”异常的直接原因。IDEA开发环境IDEA在构建项目模块的类路径时通常非常“智能”和“完整”。它会收集所有模块的依赖并基于Maven的依赖树和自身的索引构建一个类路径。关键点在于IDEA有时会“看到”并包含多个版本的jar包但它默认的类加载顺序可能恰好让你调用的版本比如fastjson2先被加载从而掩盖了冲突。你可以通过IDEA的mvn dependency:tree输出看到冲突但运行时却正常。打包后的Fat Jar以Spring Boot为例当我们使用spring-boot-maven-plugin打出一个可执行的、包含所有依赖的Fat Jar时它的类路径构建是严格且扁平的。插件会解析最终的依赖树对于同一个groupId:artifactId只会选取一个版本即Maven决议后的最终版本打入BOOT-INF/lib/。如果Maven决议错误地选择了旧版本1.2.83那么jar包里就只有1.2.83你的代码在运行时调用fastjson2的API自然就会找不到类。一个典型的错误场景项目父POM的 中声明fastjson2.version2.0.48。项目显式依赖com.alibaba.fastjson2:fastjson2:${fastjson2.version}。但是项目同时依赖了另一个第三方库com.some:old-library:1.0而这个old-library在自己的pom.xml中直接声明了依赖com.alibaba:fastjson:1.2.83。此时Maven依赖树中同时存在com.alibaba.fastjson2:fastjson2:2.0.48和com.alibaba:fastjson:1.2.83。它们是两个不同的ArtifactId(fastjson2vsfastjson)所以不会发生版本覆盖。致命陷阱你的代码中可能历史遗留原因部分类导入的仍然是import com.alibaba.fastjson.JSON;。在IDEA中由于两个jar包都在类路径里编译器能通过。但在打包时如果old-library的传递依赖被保留那么fastjson-1.2.83.jar会被打入包中。运行时JVM加载了com.alibaba.fastjson.JSON这个类来自1.2.83但它内部实现与fastjson2不兼容或者你代码中某些方法调用在新旧版本间有差异就会引发NoSuchMethodError或ClassCastException等运行时错误。注意fastjson和fastjson2的groupId和artifactId都不同它们是两个独立的库。因此问题不仅仅是版本冲突更多是“错误地引入了本应被替换的旧库”。3. 诊断与排查实战揪出隐藏的依赖元凶当遇到此类问题不要盲目猜测系统化的排查是最高效的。以下是 step-by-step 的诊断流程。3.1 第一步在项目根目录执行依赖树分析打开终端进入你的项目根目录包含pom.xml的目录执行命令mvn dependency:tree -Dverbose dependency_tree.txt-Dverbose参数至关重要它会显示所有冲突和被忽略的依赖。然后用文本编辑器打开生成的dependency_tree.txt文件。搜索关键信息搜索com.alibaba:fastjson查看是否还有1.2.x版本的依赖存在以及它是通过哪个路径传递进来的。你会看到类似下面的输出[INFO] - com.some:old-library:jar:1.0:compile [INFO] | \- com.alibaba:fastjson:jar:1.2.83:compile这就明确指出了罪魁祸首是old-library。搜索com.alibaba.fastjson2确认你期望的fastjson2版本是否在依赖树中以及它的路径。注意omitted for conflict with提示verbose模式会显示因为版本冲突而被忽略的依赖。如果看到fastjson2的某个版本被忽略说明有更“近”的声明覆盖了它你需要找到那个声明。3.2 第二步检查Maven的依赖管理部分查看项目顶层pom.xml以及所有父POM的 部分。确认fastjson2的版本是否在此处被正确定义。同时也要检查是否有其他地方比如某个profile或属性文件意外地覆盖了这个版本属性。3.3 第三步使用IDEA内置工具交叉验证IDEA提供了图形化的依赖分析工具非常直观。在IDEA中打开你的pom.xml文件。右键点击文件内容选择Maven - Show Dependencies。这会打开一个依赖图。在左上角的搜索框中输入fastjson。图表会高亮显示所有相关的依赖。你可以看到红色实线表示依赖关系。红色虚线通常表示存在版本冲突或排除。你可以点击某个库查看哪些模块依赖了它。通过这个图可以快速定位是哪个模块引入了不需要的fastjson。3.4 第四步对比打包前后的依赖有时候依赖树显示一切正常但打包结果不对。这可能和打包插件如spring-boot-maven-plugin的配置有关。解压你生成的jar包例如your-app.jar。jar -xf your-app.jar # 或者使用解压软件直接打开查看 BOOT-INF/lib/ 目录查看BOOT-INF/lib/目录下是否存在fastjson-1.2.83.jar和fastjson2-2.0.48.jar。如果两者都存在那问题就是运行时类加载顺序或代码兼容性问题。如果只有fastjson-1.2.83.jar那说明Maven决议或插件配置有问题fastjson2根本没被打进去。4. 解决方案与实操彻底清理旧依赖找到问题根源后我们有几种武器来消灭它。4.1 方案一在依赖声明中直接排除最常用对于那个引入了旧版fastjson的第三方依赖例如com.some:old-library我们在声明对其的依赖时直接排除掉传递进来的fastjson。dependency groupIdcom.some/groupId artifactIdold-library/artifactId version1.0/version exclusions exclusion groupIdcom.alibaba/groupId artifactIdfastjson/artifactId /exclusion /exclusions /dependency实操要点修改后务必再次执行mvn dependency:tree确认com.alibaba:fastjson已经从依赖树中消失。确保你的项目代码中已经完全移除了对com.alibaba.fastjson包下所有类的引用如JSON,JSONObject,JSONArray全部替换为com.alibaba.fastjson2的对应类。可以使用IDEA的全局搜索CtrlShiftF来检查。4.2 方案二在依赖管理中强制统一版本适用于多模块如果你的项目是一个多模块项目并且有多个模块可能间接引入fastjson可以在父POM的 中强制指定com.alibaba:fastjson的版本为一个空版本99.0-does-not-exist或者一个极高的无效版本从而让所有模块都无法引入它。dependencyManagement dependencies !-- 其他依赖管理 -- !-- 禁止引入 fastjson 1.x -- dependency groupIdcom.alibaba/groupId artifactIdfastjson/artifactId version99.0-does-not-exist/version /dependency !-- 正确定义 fastjson2 的版本 -- dependency groupIdcom.alibaba.fastjson2/groupId artifactIdfastjson2/artifactId version2.0.48/version /dependency /dependencies /dependencyManagement注意事项这种方法比较“暴力”可能会破坏那些真正需要fastjson 1.x且与fastjson2不兼容的依赖尽管这种情况在升级后应尽量避免。使用前需充分测试。4.3 方案三使用Maven Enforcer插件主动防御这是一种更工程化的预防措施。maven-enforcer-plugin可以定义规则在构建阶段就禁止引入特定的依赖。build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-enforcer-plugin/artifactId version3.4.1/version executions execution idenforce-banned-dependencies/id goals goalenforce/goal /goals configuration rules bannedDependencies excludes !-- 禁止任何版本的 fastjson 1.x -- excludecom.alibaba:fastjson:[,2.0)/exclude !-- 你也可以只禁止特定的危险版本如存在漏洞的版本 -- !-- excludecom.alibaba:fastjson:[1.2.24,1.2.83]/exclude -- /excludes /bannedDependencies /rules failtrue/fail /configuration /execution /executions /plugin /plugins /build配置此插件后如果任何依赖试图引入fastjson1.x版本Maven构建将会直接失败并给出明确的错误信息从而在CI/CD流程中就阻断问题而不是等到运行时才发现。4.4 方案四检查并配置打包插件确保你的spring-boot-maven-plugin或其它打包插件没有特殊的依赖处理规则。通常默认配置即可但如果你有自定义的或配置需要检查是否无意中过滤或包含了特定依赖。5. 完整升级与验证清单为了避免遗漏这里提供一个从fastjson升级到fastjson2的完整检查清单。更新依赖声明在pom.xml中将com.alibaba:fastjson依赖移除或注释掉。添加com.alibaba.fastjson2:fastjson2依赖。在 中统一管理版本推荐。全局代码替换包导入将所有import com.alibaba.fastjson.XXX替换为import com.alibaba.fastjson2.XXX。类名通常JSON,JSONObject,JSONArray,TypeReference等核心类名不变但包路径变了。注意JSONPath等类可能在fastjson2中有单独的模块。API变更fastjson2并非100%兼容。需要重点检查序列化/反序列化方法如parseObject的某些重载。Feature枚举常量有些可能已被弃用或改名如SerializerFeature,ParserFeature在fastjson2中合并或调整了。自定义序列化器/反序列化器可能需要适配新的接口。处理传递依赖使用mvn dependency:tree找出所有传递引入的com.alibaba:fastjson。在相应的依赖声明中添加 。构建与打包验证执行mvn clean compile确保编译通过。执行mvn dependency:tree确认依赖树干净无旧版fastjson。执行mvn clean package打包。解压或查看生成的jar/war包确认lib目录下只有fastjson2的jar包没有fastjson-1.x.x.jar。运行时验证在本地运行打包后的应用进行核心功能测试。特别测试涉及JSON序列化/反序列化的所有边界场景和复杂对象。6. 常见问题与避坑指南Q1排除了旧依赖后编译报错找不到fastjson的类A1这恰恰证明你的代码中还有地方在引用旧的com.alibaba.fastjson包。需要完成上述“全局代码替换”的步骤。IDEA的“Optimize Imports”功能可以帮助快速清理无用的import语句。Q2使用了排除但打包后旧版本的jar依然存在A2可能有多个不同的依赖都引入了fastjson你只排除了其中一个。再次检查完整的依赖树。也可能是打包插件如maven-shade-plugin的配置问题检查是否有将依赖重定位relocate或特殊包含的配置。Q3升级到fastjson2后序列化的日期格式、空值处理等行为和之前不一致A3这是API行为变更不是bug。fastjson2为了性能和安全性对一些默认行为做了调整。你需要仔细阅读fastjson2的官方文档或迁移指南查看JSONWriter.Feature和JSONReader.Feature等配置项并在代码中显式配置你需要的序列化/反序列化特性。Q4第三方库强制依赖fastjson 1.x且无法排除否则会导致该库功能异常怎么办A4这是最棘手的情况。可以考虑以下方案联系该库的维护者请求其升级支持或提供不依赖fastjson的版本。寻找替代库。如果必须共存确保你的业务代码只使用fastjson2。对于那个第三方库尝试通过Maven的 将其依赖的fastjson升级到一个与fastjson2包名不冲突的、较新的、漏洞已修复的1.2.x版本如1.2.84但这需要充分测试兼容性因为fastjson2和fastjson 1.x的类加载器可能会同时加载两个不同的com.alibaba.fastjson.JSON类引发难以预料的错误。强烈不推荐此方案应作为最后不得已的临时手段。个人心得这类依赖冲突问题最好的解决时机是在项目架构设计之初就建立规范。例如在父POM中通过 严格管控所有常用组件的版本使用maven-enforcer-plugin设置禁令在CI流水线中加入依赖检查步骤。对于历史项目每次升级核心组件如JSON库、日志门面、数据库驱动等时把“依赖树分析”作为规定动作防患于未然。这次从fastjson到fastjson2的升级不仅仅是一个jar包的替换更是一次对项目依赖治理能力的检验。
