应用启动直接抛 Unsupported class file major version 61，堆栈指向某个 jar。这不是依赖坏了，而是编译用的 JDK 版本比运行环境高，字节码不兼容。
数字对应哪个版本
61 对应 Java 17，55 是 Java 11，52 是 Java 8。看到 61 就说明这个类是用 JDK 17 编译的，而你现在跑在 11 或 8 上。
先核对两端版本
java -version javac -version mvn -v | head -n 3
三条输出里的版本不一致，问题就清楚了。常见于本地用新 JDK 打包，服务器或容器镜像是旧版本。
统一版本或降编译目标
在 pom.xml 里显式指定编译目标，让产物能在低版本 JDK 上运行：
11
用了 release 参数后，编译期就会拦住高版本 API 的调用，比事后运行时报错好排查。升级运行环境则要同步检查依赖，部分框架的新版本对 JDK 有硬性要求。
容器部署时把基础镜像的 JDK 版本写进 Dockerfile，别用 latest 标签，镜像一变就可能出现同样的报错。
确认是不是依赖内部传来的类
unzip -p 某个.jar 类路径.class | head -c 8 | xxd
读出前八个字节里的版本号，也能反推是哪个依赖用了高版本编译。第三方 SDK 遇到过这种情况，升级依赖通常比改运行时更省事。
本地能跑、服务器报错，九成是两端 JDK 不同，先把版本对齐再谈其他可能。