本地跑得好好的，打包部署后启动报 NoSuchMethodError，指向 guava 的 Preconditions.checkArgument，两个依赖各自带了一份不同版本。碰到这种情况，我一般先确认改动有没有真的生效。
原因不复杂，classpath 上同名类出现两个版本，类加载器只取最先加载的那份，方法签名对不上就在调用处抛错。
「jar 版本冲突」相关的验证我通常做两遍，改完一次、隔天再看一次，确认不是临时生效。改完顺手把文档补一句，省得下次自己重新推一遍。
mvn dependency:tree -Dincludes=com.google.guava:guava mvn dependency:tree -Dverbose > dep.txt
监控和日志的时间要对上，时区不一致会多绕很大一圈。临时改动用注释写上日期和原因，过两周自己都记不清为什么这么写。
动手前把原文件复制一份带时间戳，出问题立刻换回去，比现场分析快得多。一次只改一处，改完立刻验证，几个改动叠在一起，出问题就说不清是谁导致的。
具体做法是，用依赖树找出重复依赖的来源；在引入方加 exclusion 排掉旧版本；版本号统一放到父 pom 管理。
最后用这个标准收尾，依赖树里只剩一个版本，启动不再报 NoSuchMethodError。