每个人都可以，
拥有SSL证书

有时候本地跑得好好的，一上到服务器就给你扔一个 Unsupported class file major version 61，这种基本不用猜，就是 Java 版本对不上。

具体来说，这个 61 对应的是 Java 17 编译出来的 class 文件。如果你的运行时环境是 Java 11 或者 8，甚至更早的版本，它识别不了高版本编译的字节码，就会直接罢工。class 文件的 major version 和 JDK 版本之间有个固定的对应关系，61 就是 Java 17，60 是 Java 16，52 是 Java 8，55 是 Java 11，这些数字记住了排查问题会很快。

要解决的话，思路就两个方向：要么把运行环境升上去，要么把编译版本降下来。

如果你项目本身就已经在用 Java 17 的特性，那没什么好纠结的，直接升级 JRE。先跑一下 java -version 看当前的版本，如果低于 17，就去装一个 17 或者更新的 JRE。装完之后别忘了改环境变量，Windows 上在系统环境变量里把 JAVA_HOME 指到新安装的路径，再把 %JAVA_HOME%\bin 加到 Path 里。

Linux 或者 macOS 的话，编辑 ~/.bashrc 或者 ~/.bash_profile，加上 export JAVA_HOME=/path/to/java 和 export PATH=$JAVA_HOME/bin:$PATH，然后 source 一下让配置生效。最后再用 java -version 确认一下，别改了半天结果发现还在用老的。

另一个场景是线上环境固定了 Java 版本，比如一堆服务都跑在 Java 8 上，运维不给升，那你只能把编译的目标版本降下来。在 IDE 里直接改项目的 JDK 设置，Maven 或者 Gradle 也要同步改，比如 Maven 的 pom.xml 里配置 maven-compiler-plugin 的 source 和 target 都设成 8。

Gradle 的话改 sourceCompatibility 和 targetCompatibility。改完重新打个包，不要再拿之前 Java 17 编译出来的 class 上去部署了。

这里有一个容易踩的坑：版本降下来之后，有些第三方库可能不兼容旧版本，比如你用了个依赖要求 Java 11 以上，强行降到 8 就会出别的毛病。

所以改之前最好扫一眼依赖声明，或者跑一遍完整的测试。另外 IDE 自己也会缓存一些配置，有时候项目设置里改了，实际编译还是用的老的 JDK，最好清一下缓存或者直接看编译输出的日志确认一下。

不管升还是降，操作前把配置或者项目做个备份是基本操作，不然改乱了回不来就麻烦了，尤其是多人协作的项目。

顺便把 class major version 和 JDK 版本的完整对照列一下，后面再碰到别的数字可以直接查：65 是 JDK 21，64 是 JDK 20，63 是 JDK 19，62 是 JDK 18，61 是 JDK 17，60 是 JDK 16，59 是 JDK 15，58 是 JDK 14，57 是 JDK 13，56 是 JDK 12，55 是 JDK 11，54 是 JDK 10，53 是 JDK 9，52 是 JDK 8，51 是 JDK 7，50 是 JDK 6。

基本上看一眼这个对应关系，报错信息里那个数字就能直接告诉你该用哪个版本了。