java -version 仅验证运行环境，无法确认 jdk 是否完整；必须配合 javac -version 检查编译器是否存在，二者版本一致且均可执行，才表明 jdk 完整安装并正确配置。
直接运行 java -version 就能拿到版本号，但仅靠它无法确认你装的是不是完整 JDK（而非仅 JRE）。
为什么 java -version 不够用
这个命令只调用 JRE 运行时，输出的可能是 OpenJDK、Temurin、Zulu 等任意发行版的运行时版本，但它不验证编译器是否存在。很多系统预装了 JRE（比如某些云服务器镜像），java -version 能成功，但 javac 会报 command not found，导致你后续编译 Java 源码失败。
- 只运行
java -version→ 只说明 Java 运行环境就绪 - 必须再跑一次
javac -version→ 才能确认 JDK 完整安装（含编译器、tools.jar、javadoc 等） - 两者输出版本号不一致？说明 PATH 混用了不同 JDK，常见于手动配置了多个
JAVA_HOME或alternatives切换未生效
Linux/macOS 下快速双检命令
别分两行敲，用分号连起来更可靠（&& 遇错中断，; 强制执行）：
java -version 2>/dev/null || echo "❌ java missing"; javac -version 2>/dev/null || echo "❌ javac missing"
实际效果是：不管哪个失败，都会打印对应提示，且不会因前一个失败而跳过第二个检查。
- 输出类似
openjdk version "17.0.1"和javac 17.0.1→ 版本一致，JDK 就位 - 只看到第一个输出，第二行报
javac: command not found→ 缺少 JDK，或$JAVA_HOME/bin没进PATH - 两个都报错 → JDK 没装，或环境变量完全失效
查完版本，顺手确认安装路径是否靠谱
版本号只是字符串，真正影响项目构建的是实际路径。尤其在多 JDK 共存的服务器上，java -version 显示的未必是你以为的那个 JDK：
- 先看环境变量：
echo $JAVA_HOME→ 如果有输出，就去那个目录下确认是否存在bin/javac - 没设
JAVA_HOME？用which java找到命令位置，再执行readlink -f $(which java)→ 追到底层真实路径（比如指向/usr/lib/jvm/java-17-openjdk-amd64/bin/java） - 路径末尾是
/bin/java，那 JDK 根目录就是它的上级的上级（即去掉最后两级）→ 否则你配JAVA_HOME时容易错配成.../bin，导致 Maven、Gradle 找不到 tools.jar
最容易被忽略的点：PATH 里可能混进了旧 JDK 的 bin，而 JAVA_HOME 指向的是新版本——这时 java -version 和 javac -version 输出的版本号会不一致，构建工具却按 JAVA_HOME 去找库，结果出诡异错误。务必用 readlink -f $(which javac) 实锤到底用的是哪个二进制文件。
