最直接办法是两边执行java -xshowsettings:properties -version 2>&1 | grep java.home确认真实java_home路径，并运行java --list-modules | grep -i javafx比对模块差异，避免被版本号或软链接误导。
怎么确认本地和服务器用的不是同一个JDK
最直接的办法是两边都执行 java -version 和 which java，但光看输出容易被误导。比如都显示 openjdk version "17.0.11"，不代表实际是同一构建来源——Adoptium、Amazon Corretto、Oracle OpenJDK 的二进制包在模块分发、默认启用特性（如--add-opens）、甚至javafx是否内置上都有差异。
真正要对比的是运行时行为，建议在两边都跑这个命令：
java --list-modules | grep -i javafx
如果本地有输出，服务器没输出，基本就锁定是javafx缺失问题；再补一句：
java -XshowSettings:properties -version 2>&1 | grep java.home
这能暴露出真实的JAVA_HOME路径，避免被PATH里某个临时软链接骗过去。
为什么mvn compile本地过、Jenkins上失败
这不是Maven的问题，而是Maven用的JDK不同。Jenkins默认调用系统PATH里的java，而你的IDE（如IntelliJ）可能显式配置了项目级JDK路径，或者用了IDE自带的嵌入式JDK（比如IntelliJ的jbr），它自带javafx模块。
- 检查Jenkins任务配置里是否显式设置了
JDK（Jenkins → 系统配置 → 全局工具配置 → JDK安装） - 在Jenkins构建步骤开头加一条
sh 'java -XshowSettings:properties -version 2>&1'，把完整启动参数打出来 - 别只信
pom.xml里写的<java.version>17</java.version>，它只影响Maven编译器插件的source/target，不控制底层JDK版本
javafx.util.Pair找不到时该加什么依赖
OpenJDK从8开始就不带JavaFX，所以不能靠换JDK解决，必须引入外部依赖。但要注意：Java 11+之后，JavaFX已完全剥离为独立项目，不能再用老式的javafx-runtime这种包名。
正确做法是加 Maven 依赖：
<dependency><groupid>org.openjfx</groupid><artifactid>javafx-base</artifactid><version>21</version></dependency>
注意三点：
-
artifactId要按需选：javafx-base含Pair，javafx-controls含UI组件，别全引 -
version必须和你项目主JDK大版本对齐，比如用JDK 17就别硬上JavaFX 21 - Linux服务器若离线，得提前把
org.openjfx整个目录下到~/.m2/repository里，否则mvn compile会卡住
环境变量JAVA_HOME设错的典型表现
常见错误不是“找不到java”，而是“找到错的java”。比如CentOS上用yum install java-17-openjdk-devel装完，java -version显示17，但JAVA_HOME仍指向旧版/usr/lib/jvm/java-11-openjdk，结果Maven偷偷用11编译，运行时却加载17的类库，报UnsupportedClassVersionError。
验证方式很简单：
- 执行
echo $JAVA_HOME，看路径是否和which java输出的上级目录一致 - 执行
$JAVA_HOME/bin/java -version，确认它和java -version输出完全一样 - 如果用Docker或CI脚本，检查是否在
docker run或script块里覆盖了JAVA_HOME，导致和全局设置冲突
多版本共存时，JAVA_HOME永远应该指向你当前想用的那个JDK根目录，而不是/usr/bin/java这种符号链接位置。
