最直接方式是调用System.getProperty("java.version")获取JVM启动时设置的版本字符串，如"17.0.2"；需配合Runtime.version()做结构化比较，避免字符串截取错误；命令行方式用ProcessBuilder重定向stderr更可靠，但注意PATH可能指向不同JDK；编译与运行版本不一致会导致UnsupportedClassVersionError，典型如class文件版本52对应JDK 8、61对应JDK 17；IDE中项目SDK、模块语言级别、运行配置JRE三者需一致。
运行时获取 java.version 系统属性
最直接的方式是在代码中读取 JVM 启动时自动设置的系统属性。这个值稳定、无需外部命令，适合在程序启动校验或日志中记录版本。
-
System.getProperty("java.version")返回类似"17.0.2"或"1.8.0_362"的字符串，注意 JDK 9+ 去掉了"1."前缀 - 若需结构化判断（比如“是否 ≥ JDK 11”），建议配合
Runtime.version()（Java 9+）使用，它返回Runtime.Version对象，支持compareTo()和feature() - 避免只截取字符串前两位做比较（如
substring(0,2)），"17"和"1.8"格式不一致会导致逻辑错误
命令行执行 java -version 并捕获输出
当 Java 程序需要确认实际运行环境（而非编译时依赖）或做跨平台兼容检查时，调用系统命令更可靠——尤其在容器或 CI 环境中，JDK 可能被动态替换。
- 用
Runtime.getRuntime().exec("java -version")无法直接读取标准输出，因为-version输出到stderr，必须显式重定向或读取getErrorStream() - 推荐改用
ProcessBuilder并合并流：new ProcessBuilder("java", "-version") .redirectErrorStream(true) .start() .getInputStream() - 注意：该方式依赖 PATH 中的
java可执行文件，可能与当前 JVM 不一致（例如用 JDK 8 运行程序，但 PATH 指向 JDK 17 的java）
编译期 vs 运行期版本不一致的典型表现
很多“版本报错”其实源于编译和运行使用的 JDK 不匹配，比如 UnsupportedClassVersionError 就是典型信号。
- 错误信息形如：
java.lang.UnsupportedClassVersionError: XXX has been compiled by a more recent version of the Java Runtime (class file version 61.0), this version of the Java Runtime only recognizes class file versions up to 52.0 - 其中
61.0对应 JDK 17，52.0对应 JDK 8 —— 数字对应关系可查 Oracle 官方文档，但更实用的是记住：JDK 8 → 52，JDK 11 → 55，JDK 17 → 61，JDK 21 → 65 - Maven 用户需同步检查
maven-compiler-plugin的source/target与JAVA_HOME指向的 JDK 是否一致
IDE 中容易忽略的 JDK 配置层级
IntelliJ 或 Eclipse 里看似设置了 JDK，但仍有多个地方可能覆盖实际行为。
立即学习“Java免费学习笔记（深入）”；
- 项目 SDK（Project SDK）决定编译器和语法高亮
- 模块语言级别（Module language level）可能低于项目 SDK，导致新语法（如
var）被禁用 - 运行配置（Run Configuration）里的 JRE 设置，会覆盖项目 SDK，单独指定运行时 JDK
- Maven/Gradle 导入时可能重置 SDK，尤其是从
pom.xml读取java.version属性后自动切换
java -version 或 IDE 状态栏数字，不一定反映你代码实际运行的环境。 
