如果你也遇到过这种情况——本地编译明明通过把工程挪了个目录或者把依赖的jar包单独拷到另一台机器结果一启动就甩给你一堆ClassNotFoundException、NoClassDefFoundError甚至直接一个NoSuchMethodError那你今天算来对了。我写Java有十来年了几乎每年都会收到几个类似的求助问题本身不复杂但排查路径不对会绕很久。这篇就把jar包移动之后报错的常见原因、排查流程和避坑心得一次讲透适合刚入行的Java开发也适合用Maven/IDEA打包、在SpringBoot项目里引过本地jar包的人。先说一个可能颠覆认知的点jar包“移动”这个动作本身通常不会损坏jar包真正出问题的是“移动之后运行时找jar包的方式变了”。classpath变了、依赖树缺了一环、某个类有两个版本、原生库没跟上——这些才是报错背后的真凶。下面按排查思路来拆。1. 先搞明白jar包移动后的报错到底错在哪一层1.1 三类最典型的报错名词别再混为一谈新手最容易把几个名字很像的异常搞混ClassNotFoundException、NoClassDefFoundError、NoSuchMethodError。它们的含义和排查方向完全不同。ClassNotFoundException是一个Exception意思很直白JVM在加载时根本找不到这个类。比如你手动java -cp指向的路径里没包含这个jar或者Maven依赖里压根没声明它。这类报错有个特点报错信息里直接给出缺失的类名路径也基本不用猜。NoClassDefFoundError则是一个Error很多人在这一步就懵了。它并不是说“没找到类”而是说“这个类在编译期是存在的但运行时加载阶段失败了”。最常见的原因是你移动了主jar包但它依赖的另一个jar包没跟着移动。JVM加载这个类时类依赖的其他类不存在于是整个类加载失败最终抛NoClassDefFoundError。打个比方ClassNotFoundException是你打电话找人对方停机了NoClassDefFoundError是你叫了一个外卖结果外卖小哥在路上被拦了你没收到餐但外卖单子是存在的。所以看到NoClassDefFoundError一定不要只盯着报错的那个类名要往它的依赖链上查。至于NoSuchMethodError / NoSuchFieldError这是典型的版本冲突。程序的某个类调用另一个类的方法但实际加载到的那个类里没有这个方法或者方法签名变了。常见于同一个jar包的不同版本同时出现在classpath里运行时加载了旧版本。这种情况单纯“补依赖”没用得做版本仲裁。1.2 除了类加载报错还有一类“不动声色”的本地库报错除了上面三个还有一个很容易被忽略的UnsatisfiedLinkError。它的典型场景是——你把一个带native代码的jar包比如gdal、opencv这类需要调用底层C/C库的包移动到了新环境但jar包对应的.dll或.so文件没跟着走。JVM通过JNI去找本地库找不到就抛UnsatisfiedLinkError。这类报错表面上也是“jar包移动后报错”但根本原因在jar包外面在操作系统层面的原生库路径。注意如果报错信息里出现“java.lang.UnsatisfiedLinkError: no xxx in java.library.path”别急着在Java代码里找问题先去确认对应的原生库文件是否存在于系统路径或者是否通过-Djava.library.path指定了正确目录。2. 我最常踩的4个坑移动jar包报错的核心原因2.1 依赖没有跟着走只移动了一个jar包却没带上它的依赖树很多项目在早期都是手动管理jar包直接把依赖的jar文件扔在lib目录里。问题来了jar包之间是有依赖关系的。你单独把A.jar拷走但A.jar内部引用的B、C、D类都在别的jar里新环境只有A.jar那运行到某个功能时JVM自然给你一个NoClassDefFoundError。这个坑在gdal这类“大而全”的依赖上尤其明显。我见过有人把gdal jar包从一个旧项目里复制出来丢到新项目的lib下结果一调用GDAL的接口就报UnsatisfiedLinkError或ClassNotFoundException。原因很简单gdal官方提供的jar包往往依赖一堆附属包和本地的原生库光移动一个jar包是不够的。正确处理方式有两种要么用Maven/Gradle按坐标管理依赖让工具帮你把整个依赖树下载完整要么手动移动jar包时把整个依赖目录比如lib下所有相关jar一起拷走而不是只拷某一个。对于SpringBoot项目更推荐直接打成可执行jar让插件把依赖统一打进BOOT-INF/lib里。2.2 同一套代码里出现两个同名类版本冲突才是最大的坑移动jar包之后还有一种很诡异的报错明明类都在方法也能找到但运行到一个内部方法时突然抛NoSuchMethodError或者更隐蔽的数据算出来的结果不对。这种情况十有八九是版本冲突。举个例子项目A依赖X组件1.2版项目B依赖X组件2.0版你把两个项目合并到一起或者移动jar包时classpath里同时出现了X-1.2.jar和X-2.0.jar。如果加载顺序让JVM优先加载了老版本而老版本里没有新版本才有的方法那调用时就是NoSuchMethodError。更麻烦的是有些包连类名都一样静态变量、方法签名也差不多但内部逻辑完全不同运行起来行为诡异排查起来非常耗时间。用Maven时可以通过mvn dependency:tree -Dverbose看到完整依赖树找出同一个groupId下的多个版本。然后通过exclusion排除不需要的旧版本或者用dependencyManagement统一版本。手动管理的项目就得靠你逐一核对lib目录下的jar包了。2.3 路径写死了本地能跑换电脑就挂有一类报错和classpath无关是代码里写死了路径。很多人移动jar包后一启动就报“文件不存在”或者“找不到配置文件”第一反应是去看classpath结果越查越偏。比较典型的写法是String path new File(lib/xxx.jar).getAbsolutePath();System.setProperty(my.conf, ./conf/app.properties);用user.dir拼接路径再读取外部资源。这些代码在本地开发时目录结构是固定的所以能正常运行。但你把项目移到服务器或者把jar包挪到别的目录user.dir变了相对路径自然失效。我的建议是需要读取jar包内部资源时用ClassPathResource / getResourceAsStream不要把路径写死需要引用外部文件时优先通过启动参数传入绝对路径或者约定一个统一的配置目录而不是依赖程序当前工作目录。2.4 打包配置把本地jar包“遗忘”了这个坑在IDEA Maven项目里非常高频。你有一个本地jar包不在中央仓库于是直接在IDEA的Project Structure里添加了依赖代码里import也没问题。但当你执行mvn package或者用spring-boot:run启动时突然报ClassNotFoundException。原因在于IDEA里手动添加的jar包只存在于IDE的编译classpath里并不会自动写进pom.xml更不会跟着Maven的打包流程进到最终产物。如果你的项目是SpringBoot的打出来的可执行jar里BOOT-INF/lib下根本没有这个本地jar包运行环境自然找不到类。解决方案有三种用mvn install:install-file命令把本地jar包安装到本地Maven仓库然后在pom.xml里用普通dependency引用在pom.xml的dependency里将scope设为system并指定systemPath同时需要配置spring-boot-maven-plugin的includeSystemScopetrue否则SpringBoot打包时不会包含system scope依赖如果只是临时测试可以直接在IDEA里设置“Add JARs to Artifact”但这种方式不适合作为长期方案。注意从Maven 3.8开始部分本地仓库配置比如用file://协议指定外部仓库会有安全限制如果你用第二种方式遇到“unresolved dependency”报错先检查本地仓库配置的镜像和repo id是否对应。3. 一套能复用的排查流程从报错到定位的完整实操3.1 第一步确认报错发生在哪个阶段看到报错后第一件事不是搜报错信息而是看堆栈发生的时间点。编译期报错、启动期报错、运行期报错的排查方向完全不一样。编译期报错通常是classpath没配好或者pom里缺依赖。IDEA里表现为“程序包不存在”Maven里表现为“cannot find symbol”。这种情况先检查依赖坐标是否写对以及本地仓库是否有对应jar包。启动期报错类加载异常通常发生在Spring容器启动、Bean初始化、静态代码块执行这些阶段。报错往往和Bean创建有关比如“Error creating bean with name xxx”然后背后跟着ClassNotFoundException或NoClassDefFoundError。运行期报错调用某个功能时才报最能迷惑人。比如项目启动没问题一点某个按钮就NoSuchMethodError这通常说明相关类在classpath里但加载的版本不对或者某个懒加载依赖缺失。确认阶段之后就可以缩小搜索范围。启动期和运行期的报错尤其要看堆栈里的“Caused by”有时真正的原因藏在链尾被一堆框架代码包着。3.2 第二步用这几条命令快速判断依赖状态这一步是排查核心我几乎每次都会用。假设你怀疑某个类缺失或版本不对可以先查当前项目到底有哪些依赖。如果是Maven项目先跑mvn dependency:tree -Dverbose这样能把所有依赖的版本和依赖关系打印出来如果同一个类被多个jar包引用这里会显示冲突。加-Dverbose是为了显示更详细的包名信息方便对照报错中的类名。然后如果你手上有一个具体jar包想确认里面到底有没有某个类可以用jar tf xxx.jar | grep 某个类名或者用更直接的unzip -p xxx.jar META-INF/MANIFEST.MF查看这个jar包的Class-Path和Main-Class信息有时候问题就出在MANIFEST.MF里指定的Class-Path目录不对。3.3 第三步手工验证缺失的类到底在不在如果报错信息里给了具体的类名比如“org.apache.commons.io.IOUtils”你可以在本地仓库里搜一下find ~/.m2/repository -name *.jar | xargs -I{} sh -c jar tf {} | grep org/apache/commons/io/IOUtils.class echo {}这种穷举命令略笨但能很直观地告诉你这个类在哪个jar包里以及你当前的classpath里到底有没有包含那个jar。有时候类确实在但报NoSuchMethodError那就需要用javap反编译看一下方法签名。比如javap -classpath . -c org.apache.commons.io.IOUtils | grep 某个方法如果方法签名对不上说明当前加载的不是你预期的那一版jar。3.4 第四步修改后如何验证避免越改越乱改完pom或调整jar包之后不要只看“不报错了”就完事建议做两步验证。第一步重新使用mvn clean package在干净环境下打包确保本地仓库的状态是最新的避免IDE缓存把旧的依赖又带进来。第二步启动时加JVM参数java -verbose:class -jar your-app.jar-verbose:class会在控制台打印每个类是从哪个jar加载的。假如你怀疑某个类版本不对直接启动后grep类名看它的来源路径是不是你想要的。没有这个参数的话也可以用arthas进入交互模式后执行sc -d某个类名同样能查到ClassLoader和jar包来源。这一步的价值在于它能把“猜测”变成“眼见为实”。很多冲突排查了半天最后发现是IDEA的缓存没有刷新加了-verbose:class一眼就能看出来。4. 常见问题速查表 我的避坑心得4.1 常见问题速查表我在下表里整理了几种最典型的“jar包移动后报错”场景方便你对号入座报错现象可能原因推荐排查手段ClassNotFoundExceptionclasspath没包含目标jar或依赖声明缺失检查pom依赖、java -cp参数、lib目录NoClassDefFoundError主类存在但依赖链上的某个类缺失查依赖树看报错类依赖了谁NoSuchMethodError同一类存在多个版本加载了旧版dependency:tree、-verbose:class定位来源UnsatisfiedLinkErrornative库缺失或路径不对检查DLL/SO文件设置java.library.pathMaven打包后运行找不到本地jarIDEA里的lib没进入pom和打包产物install:install-file或includeSystemScopeunresolved dependency本地仓库坐标、镜像或repo配置错误检查settings.xml、pom坐标、版本号4.2 移动jar包前我建议你养成这几个好习惯最后说几点这些年总结的习惯看起来不起眼但能省很多事。第一不要直接从一个项目里复制jar包到另一个项目。即使两个项目看起来用的是同一个框架版本和依赖链也未必一样。更好的做法是找到这个jar包对应的Maven坐标由构建工具自动下载。实在没有中央仓库坐标你也应该把原项目的pom或依赖清单一起带过来再手工核对。第二移动jar包时把依赖树一起移动。如果是手动管理别只拷单个jar把整个lib目录压缩带走到了新环境再解压。如果是SpringBoot项目直接打可执行jar用BOOT-INF/lib统一携带依赖能少掉一大半问题。第三修改依赖之后不要只“运行一下不报错”就结束至少启动项目把主要功能点都点一遍尤其是涉及反射、动态加载或者JNI调用的功能。很多NoClassDefFoundError是懒加载不调用相关方法根本不会暴雷。第四看到UnknownError、ClassCastException这种不明显报错时多想想“是不是两个jar包有重复类”。我遇到过有人把commons-logging和commons-logging-api同时引入结果一直报ClassCastException浪费了一整天。排查这类问题最快的方法就是dependency:tree 全盘的jar清单核对。我在实际工作中还有一个百试百灵的小技巧把当前项目的完整依赖列表导出一份存成文本文件如果下次换了环境再报错直接diff两份依赖清单哪个jar多了少了一眼就看出来。这个习惯让我在排查“jar包移动报错”时很少走弯路。如果你也经常跟jar包打交道可以试着用起来。
jar包移动后报错排查指南：ClassNotFoundException、依赖冲突一次讲透
如果你也遇到过这种情况——本地编译明明通过把工程挪了个目录或者把依赖的jar包单独拷到另一台机器结果一启动就甩给你一堆ClassNotFoundException、NoClassDefFoundError甚至直接一个NoSuchMethodError那你今天算来对了。我写Java有十来年了几乎每年都会收到几个类似的求助问题本身不复杂但排查路径不对会绕很久。这篇就把jar包移动之后报错的常见原因、排查流程和避坑心得一次讲透适合刚入行的Java开发也适合用Maven/IDEA打包、在SpringBoot项目里引过本地jar包的人。先说一个可能颠覆认知的点jar包“移动”这个动作本身通常不会损坏jar包真正出问题的是“移动之后运行时找jar包的方式变了”。classpath变了、依赖树缺了一环、某个类有两个版本、原生库没跟上——这些才是报错背后的真凶。下面按排查思路来拆。1. 先搞明白jar包移动后的报错到底错在哪一层1.1 三类最典型的报错名词别再混为一谈新手最容易把几个名字很像的异常搞混ClassNotFoundException、NoClassDefFoundError、NoSuchMethodError。它们的含义和排查方向完全不同。ClassNotFoundException是一个Exception意思很直白JVM在加载时根本找不到这个类。比如你手动java -cp指向的路径里没包含这个jar或者Maven依赖里压根没声明它。这类报错有个特点报错信息里直接给出缺失的类名路径也基本不用猜。NoClassDefFoundError则是一个Error很多人在这一步就懵了。它并不是说“没找到类”而是说“这个类在编译期是存在的但运行时加载阶段失败了”。最常见的原因是你移动了主jar包但它依赖的另一个jar包没跟着移动。JVM加载这个类时类依赖的其他类不存在于是整个类加载失败最终抛NoClassDefFoundError。打个比方ClassNotFoundException是你打电话找人对方停机了NoClassDefFoundError是你叫了一个外卖结果外卖小哥在路上被拦了你没收到餐但外卖单子是存在的。所以看到NoClassDefFoundError一定不要只盯着报错的那个类名要往它的依赖链上查。至于NoSuchMethodError / NoSuchFieldError这是典型的版本冲突。程序的某个类调用另一个类的方法但实际加载到的那个类里没有这个方法或者方法签名变了。常见于同一个jar包的不同版本同时出现在classpath里运行时加载了旧版本。这种情况单纯“补依赖”没用得做版本仲裁。1.2 除了类加载报错还有一类“不动声色”的本地库报错除了上面三个还有一个很容易被忽略的UnsatisfiedLinkError。它的典型场景是——你把一个带native代码的jar包比如gdal、opencv这类需要调用底层C/C库的包移动到了新环境但jar包对应的.dll或.so文件没跟着走。JVM通过JNI去找本地库找不到就抛UnsatisfiedLinkError。这类报错表面上也是“jar包移动后报错”但根本原因在jar包外面在操作系统层面的原生库路径。注意如果报错信息里出现“java.lang.UnsatisfiedLinkError: no xxx in java.library.path”别急着在Java代码里找问题先去确认对应的原生库文件是否存在于系统路径或者是否通过-Djava.library.path指定了正确目录。2. 我最常踩的4个坑移动jar包报错的核心原因2.1 依赖没有跟着走只移动了一个jar包却没带上它的依赖树很多项目在早期都是手动管理jar包直接把依赖的jar文件扔在lib目录里。问题来了jar包之间是有依赖关系的。你单独把A.jar拷走但A.jar内部引用的B、C、D类都在别的jar里新环境只有A.jar那运行到某个功能时JVM自然给你一个NoClassDefFoundError。这个坑在gdal这类“大而全”的依赖上尤其明显。我见过有人把gdal jar包从一个旧项目里复制出来丢到新项目的lib下结果一调用GDAL的接口就报UnsatisfiedLinkError或ClassNotFoundException。原因很简单gdal官方提供的jar包往往依赖一堆附属包和本地的原生库光移动一个jar包是不够的。正确处理方式有两种要么用Maven/Gradle按坐标管理依赖让工具帮你把整个依赖树下载完整要么手动移动jar包时把整个依赖目录比如lib下所有相关jar一起拷走而不是只拷某一个。对于SpringBoot项目更推荐直接打成可执行jar让插件把依赖统一打进BOOT-INF/lib里。2.2 同一套代码里出现两个同名类版本冲突才是最大的坑移动jar包之后还有一种很诡异的报错明明类都在方法也能找到但运行到一个内部方法时突然抛NoSuchMethodError或者更隐蔽的数据算出来的结果不对。这种情况十有八九是版本冲突。举个例子项目A依赖X组件1.2版项目B依赖X组件2.0版你把两个项目合并到一起或者移动jar包时classpath里同时出现了X-1.2.jar和X-2.0.jar。如果加载顺序让JVM优先加载了老版本而老版本里没有新版本才有的方法那调用时就是NoSuchMethodError。更麻烦的是有些包连类名都一样静态变量、方法签名也差不多但内部逻辑完全不同运行起来行为诡异排查起来非常耗时间。用Maven时可以通过mvn dependency:tree -Dverbose看到完整依赖树找出同一个groupId下的多个版本。然后通过exclusion排除不需要的旧版本或者用dependencyManagement统一版本。手动管理的项目就得靠你逐一核对lib目录下的jar包了。2.3 路径写死了本地能跑换电脑就挂有一类报错和classpath无关是代码里写死了路径。很多人移动jar包后一启动就报“文件不存在”或者“找不到配置文件”第一反应是去看classpath结果越查越偏。比较典型的写法是String path new File(lib/xxx.jar).getAbsolutePath();System.setProperty(my.conf, ./conf/app.properties);用user.dir拼接路径再读取外部资源。这些代码在本地开发时目录结构是固定的所以能正常运行。但你把项目移到服务器或者把jar包挪到别的目录user.dir变了相对路径自然失效。我的建议是需要读取jar包内部资源时用ClassPathResource / getResourceAsStream不要把路径写死需要引用外部文件时优先通过启动参数传入绝对路径或者约定一个统一的配置目录而不是依赖程序当前工作目录。2.4 打包配置把本地jar包“遗忘”了这个坑在IDEA Maven项目里非常高频。你有一个本地jar包不在中央仓库于是直接在IDEA的Project Structure里添加了依赖代码里import也没问题。但当你执行mvn package或者用spring-boot:run启动时突然报ClassNotFoundException。原因在于IDEA里手动添加的jar包只存在于IDE的编译classpath里并不会自动写进pom.xml更不会跟着Maven的打包流程进到最终产物。如果你的项目是SpringBoot的打出来的可执行jar里BOOT-INF/lib下根本没有这个本地jar包运行环境自然找不到类。解决方案有三种用mvn install:install-file命令把本地jar包安装到本地Maven仓库然后在pom.xml里用普通dependency引用在pom.xml的dependency里将scope设为system并指定systemPath同时需要配置spring-boot-maven-plugin的includeSystemScopetrue否则SpringBoot打包时不会包含system scope依赖如果只是临时测试可以直接在IDEA里设置“Add JARs to Artifact”但这种方式不适合作为长期方案。注意从Maven 3.8开始部分本地仓库配置比如用file://协议指定外部仓库会有安全限制如果你用第二种方式遇到“unresolved dependency”报错先检查本地仓库配置的镜像和repo id是否对应。3. 一套能复用的排查流程从报错到定位的完整实操3.1 第一步确认报错发生在哪个阶段看到报错后第一件事不是搜报错信息而是看堆栈发生的时间点。编译期报错、启动期报错、运行期报错的排查方向完全不一样。编译期报错通常是classpath没配好或者pom里缺依赖。IDEA里表现为“程序包不存在”Maven里表现为“cannot find symbol”。这种情况先检查依赖坐标是否写对以及本地仓库是否有对应jar包。启动期报错类加载异常通常发生在Spring容器启动、Bean初始化、静态代码块执行这些阶段。报错往往和Bean创建有关比如“Error creating bean with name xxx”然后背后跟着ClassNotFoundException或NoClassDefFoundError。运行期报错调用某个功能时才报最能迷惑人。比如项目启动没问题一点某个按钮就NoSuchMethodError这通常说明相关类在classpath里但加载的版本不对或者某个懒加载依赖缺失。确认阶段之后就可以缩小搜索范围。启动期和运行期的报错尤其要看堆栈里的“Caused by”有时真正的原因藏在链尾被一堆框架代码包着。3.2 第二步用这几条命令快速判断依赖状态这一步是排查核心我几乎每次都会用。假设你怀疑某个类缺失或版本不对可以先查当前项目到底有哪些依赖。如果是Maven项目先跑mvn dependency:tree -Dverbose这样能把所有依赖的版本和依赖关系打印出来如果同一个类被多个jar包引用这里会显示冲突。加-Dverbose是为了显示更详细的包名信息方便对照报错中的类名。然后如果你手上有一个具体jar包想确认里面到底有没有某个类可以用jar tf xxx.jar | grep 某个类名或者用更直接的unzip -p xxx.jar META-INF/MANIFEST.MF查看这个jar包的Class-Path和Main-Class信息有时候问题就出在MANIFEST.MF里指定的Class-Path目录不对。3.3 第三步手工验证缺失的类到底在不在如果报错信息里给了具体的类名比如“org.apache.commons.io.IOUtils”你可以在本地仓库里搜一下find ~/.m2/repository -name *.jar | xargs -I{} sh -c jar tf {} | grep org/apache/commons/io/IOUtils.class echo {}这种穷举命令略笨但能很直观地告诉你这个类在哪个jar包里以及你当前的classpath里到底有没有包含那个jar。有时候类确实在但报NoSuchMethodError那就需要用javap反编译看一下方法签名。比如javap -classpath . -c org.apache.commons.io.IOUtils | grep 某个方法如果方法签名对不上说明当前加载的不是你预期的那一版jar。3.4 第四步修改后如何验证避免越改越乱改完pom或调整jar包之后不要只看“不报错了”就完事建议做两步验证。第一步重新使用mvn clean package在干净环境下打包确保本地仓库的状态是最新的避免IDE缓存把旧的依赖又带进来。第二步启动时加JVM参数java -verbose:class -jar your-app.jar-verbose:class会在控制台打印每个类是从哪个jar加载的。假如你怀疑某个类版本不对直接启动后grep类名看它的来源路径是不是你想要的。没有这个参数的话也可以用arthas进入交互模式后执行sc -d某个类名同样能查到ClassLoader和jar包来源。这一步的价值在于它能把“猜测”变成“眼见为实”。很多冲突排查了半天最后发现是IDEA的缓存没有刷新加了-verbose:class一眼就能看出来。4. 常见问题速查表 我的避坑心得4.1 常见问题速查表我在下表里整理了几种最典型的“jar包移动后报错”场景方便你对号入座报错现象可能原因推荐排查手段ClassNotFoundExceptionclasspath没包含目标jar或依赖声明缺失检查pom依赖、java -cp参数、lib目录NoClassDefFoundError主类存在但依赖链上的某个类缺失查依赖树看报错类依赖了谁NoSuchMethodError同一类存在多个版本加载了旧版dependency:tree、-verbose:class定位来源UnsatisfiedLinkErrornative库缺失或路径不对检查DLL/SO文件设置java.library.pathMaven打包后运行找不到本地jarIDEA里的lib没进入pom和打包产物install:install-file或includeSystemScopeunresolved dependency本地仓库坐标、镜像或repo配置错误检查settings.xml、pom坐标、版本号4.2 移动jar包前我建议你养成这几个好习惯最后说几点这些年总结的习惯看起来不起眼但能省很多事。第一不要直接从一个项目里复制jar包到另一个项目。即使两个项目看起来用的是同一个框架版本和依赖链也未必一样。更好的做法是找到这个jar包对应的Maven坐标由构建工具自动下载。实在没有中央仓库坐标你也应该把原项目的pom或依赖清单一起带过来再手工核对。第二移动jar包时把依赖树一起移动。如果是手动管理别只拷单个jar把整个lib目录压缩带走到了新环境再解压。如果是SpringBoot项目直接打可执行jar用BOOT-INF/lib统一携带依赖能少掉一大半问题。第三修改依赖之后不要只“运行一下不报错”就结束至少启动项目把主要功能点都点一遍尤其是涉及反射、动态加载或者JNI调用的功能。很多NoClassDefFoundError是懒加载不调用相关方法根本不会暴雷。第四看到UnknownError、ClassCastException这种不明显报错时多想想“是不是两个jar包有重复类”。我遇到过有人把commons-logging和commons-logging-api同时引入结果一直报ClassCastException浪费了一整天。排查这类问题最快的方法就是dependency:tree 全盘的jar清单核对。我在实际工作中还有一个百试百灵的小技巧把当前项目的完整依赖列表导出一份存成文本文件如果下次换了环境再报错直接diff两份依赖清单哪个jar多了少了一眼就看出来。这个习惯让我在排查“jar包移动报错”时很少走弯路。如果你也经常跟jar包打交道可以试着用起来。
