企业官网建设流程全解析

1. 这个问题到底卡在哪：你以为的 JDK 和实际生效的 JDK

先把这个场景摆出来：你装了 JDK 8，系统环境变量JAVA_HOME也指向它，命令行敲java -version显示的是 1.8。但 IDEA 里 Project Structure 选的却是 17。这时候你在 IDEA 里直接点 Run 启动 Spring Boot，程序到底跑在哪个 Java 上？

很多开发者在第一次遇到这个问题时都会愣一下。直觉上“系统的环境变量是 8，那肯定跑 8 吧”，结果实际跑起来发现日志、字节码版本、依赖兼容性全都不对劲。我当年踩这个坑时，花了大半天时间排查一个诡异的UnsupportedClassVersionError，最后才发现根本不是代码问题，而是“我以为的 JDK 和实际生效的 JDK”根本不是同一个。

这个问题的本质是：同一个机器上存在多个 Java 版本时，不同启动方式会读取不同来源的 Java 路径配置。IDEA 内置的 Project SDK 是一套独立于系统环境变量的配置，它在 IDE 内部形成了一条“虚拟 Java 环境”的通道。当你点那个绿色的 Run 按钮时，IDEA 会用自己的配置去选择 JRE，而不是去读操作系统的PATH或JAVA_HOME。

所以一句话回答标题：在 IDEA 里点启动，用 17；在命令行用 Maven 或 Java 命令启动，用 8。但真实场景远不止这么简单，因为这里面还牵扯到 Maven 编译期的 JDK、IDEA 的 Runner 设置、Spring Boot 插件的 fork 行为等等。下面我按实际排查思路来拆。

2. 两个 JDK 分别管什么：系统环境变量和 IDEA 内置配置的分工

2.1 系统环境变量JAVA_HOME到底影响谁

系统环境变量里的JAVA_HOME影响的不是你启动 IDEA 之后创建的那些进程，而是基于命令行的工具链。说白了，JAVA_HOME是给那些不通过 IDE 启动 Java 的程序用的——你在终端里敲mvn、gradle、java -jar，这些命令会去找JAVA_HOME或者PATH里的java可执行文件。

JAVA_HOME本身的优先级在所有基于命令行的 Java 调用里是最高的，因为很多脚本（比如 Maven 的mvn脚本、Tomcat 的startup.sh、各种 CI 流水线）都会先读JAVA_HOME来确定用哪个 JDK。当你的JAVA_HOME指向 JDK 8，那么这些工具启动的任何 JVM 进程都是运行在 Java 8 上的。

有一个很容易被忽略的细节：PATH和JAVA_HOME是两回事。PATH决定的是你在命令行敲java时系统找到哪个java.exe，而JAVA_HOME决定的是一些脚本工具内部去调用的路径。大部分时候你配置好JAVA_HOME也会顺手把%JAVA_HOME%\bin加进PATH，让两个保持一致。但如果这两个变量不一致，甚至你压根没配JAVA_HOME，那命令行工具的指向就会出现偏差。

2.2 IDEA 的 Project SDK 和 Project Structure

IDEA 不会傻乎乎地每次启动程序都去读系统环境变量，它有自己的一套 Java 版本管理。在File → Project Structure → Project里，你看到的Project SDK就是当前项目“名义”上的 Java 版本。这个 SDK 可以是你本机安装的任何 JDK/JRE，也可以是 IDEA 内置的 JDK（比如新版 IDEA 自带的 JBR 17）。

当你点击 Run 按钮启动 Spring Boot 时，IDEA 的建进程逻辑是这样的：它拿到 Project SDK 指向的 JVM 路径，然后把系统属性、classpath、启动类全部传给这个 JVM 来执行。这是 IDE 的主进程创建逻辑，不会经过操作系统的JAVA_HOME。所以如果你在 Project Structure 里选的是 17，那你项目启动的实际 JVM 就是 17。

但这里有个容易误导人的地方：IDEA 的Settings → Build, Execution, Deployment → Build Tools → Maven → Importing里，有个 “JDK for importer” 的选项，它影响的是 Maven 项目导入时的模型解析，不直接影响运行时的 JVM。而真正影响运行时的，除了 Project SDK，还有 Run Configuration 里的 JRE 选项——我后面会单独讲。

2.3 命令行启动和 IDEA 启动的真正区别

现在用一张对比图来理解这两个启动通道：

这个表格基本上把问题说透了。你可能已经发现了，IDEA 和命令行两套体系各自独立，互相之间没有联动。你在系统里把JAVA_HOME改成再乱，只要 IDEA 里的 Project SDK 还定格在 17，点 Run 按钮就是 17。

这里我想强调一点：这不是“BUG”，而是设计如此。IDE 为了确保可移植性和多项目并行开发的灵活性，把 JDK 配置做成了“项目级别”的独立配置，而不是依赖操作系统。但如果开发者没有意识到这套机制，就会陷入“为什么我改了环境变量没反应”的困惑。

3. 真正决定启动版本的两个隐藏开关

3.1 Run Configuration 里的 JRE 选项被大多数人忽略了

绝大多数人不知道，IDEA 的每个 Run Configuration（就是那个绿色的下拉框，Spring Boot 应用启动项）里，还有一档 JRE 选择。正常情况下它显示Default (Project SDK)，表示与 Project SDK 保持一致。但如果你曾经手动改过它，那它会拥有凌驾于 Project SDK 之上的优先级。

路径是：Run → Edit Configurations → 选择你的 Spring Boot 启动类 → 看 JRE 区域。下拉框里除了Default (Project SDK)之外，还会列出所有 IDEA 已知的 JDK/JRE 路径。一旦你在这里选了一个具体的 JDK，IDEA 在启动该项目时就会直接用这个 JDK，不管 Project SDK 是什么。

我踩过的一次坑就是：Project SDK 设置了 17，但 Run Configuration 里的 JRE 不知道什么时候被 IDE 自动改成了 8。启动 Spring Boot 后日志里明明打印着 Java 8，我却还在怀疑是不是 Maven 编译期的问题。后来点开 Edit Configurations 一看，果然是被之前某次调试时手动切换过的。所以排查版本问题时的第一步，就是去 Run Configuration 里确认 JRE 到底选的是不是默认。

3.2 Maven 编译期的 JDK 如何反噬 Spring Boot 的运行

Spring Boot 程序的启动流程比普通 Java 应用多了一层：它先经过 Maven 的compile阶段，再通过spring-boot:run或java -jar启动。在 IDEA 里点 Run 按钮，本质上执行的是 IDEA 为 Maven 项目准备的运行器（基于 Maven 的插件扩展），它会经历编译期和运行期两个 JVM 决策。

编译期的问题在于：IDEA 的 Maven 项目在Settings → Build Tools → Maven → Runner → JRE里有一个JRE设置。这个 JRE 决定了启动 Maven 本身的那个 JVM，以及编译用的 Javac 所运行的 Java 版本。如果这个设置指向 JDK 8，而你的 Project SDK 是 17，你可能会看到编译报错说“无效的目标发行版：17”——这个报错是 Maven 编译期用的是 JDK 8 的 Javac，不支持--release 17导致的。

更隐蔽的情况是：Maven 的pom.xml里通过maven-compiler-plugin的source和target指定了1.8，但 Project SDK 是 17。这时 Javac 如果用的是 17，用-source 8 -target 8去编译，也能编译通过，但会有一个比较隐蔽的坑：Javac 在 9 之后对source/target小于 8 会报警告，甚至在未来的版本会直接禁止低于 8 的source。而 Spring Boot 2.x 系列很多功能在 Java 17 上运行是没问题的，但如果编译期是 8、运行期是 17，class 文件会被编译成 52.0 版本（Java 8），跑在 17 的 JVM 上倒是没问题，因为 JVM 是向后兼容的，但反过来就不行——编译成 61.0（Java 17）的 class 跑在 Java 8 的 JVM 上会直接抛UnsupportedClassVersionError。

3.3 Spring Boot Maven 插件的 fork 逻辑

Spring Boot 的spring-boot-maven-plugin在spring-boot:run执行时，默认会 fork 一个新的 JVM 来运行你的应用程序。这个派生的 JVM 用的是哪个 Java？答案是：Maven 当前运行的那个 JVM的路径。也就是说，如果你通过命令行执行mvn spring-boot:run，并且 Maven 运行在 JDK 8 上，那么即使你的代码是 Java 17 编译的，Spring Boot 也会尝试用 JDK 8 的java来启动——然后就会因为 class 文件版本不兼容而崩溃。

但你在 IDEA 里点击 Run 按钮时，情况不太一样。IDEA 的 Spring Boot 运行器会读取上面的 Run Configuration 里的 JRE 设置，直接基于那个 JVM 来 fork 一个新进程，并不会走命令行那套 Maven 脚本逻辑。这就导致了一个非常分裂的现实：

• 同一份代码，IDEA 点按钮启动，跑在 17
• 同一份代码，命令行mvn spring-boot:run启动，跑在 8

这个分裂是合理的，因为它遵循的是各自通道的配置规则。但对于一个团队项目来说，这种分裂是隐患——你的代码在本地 IDEA 里跑得好好的，上到服务器或者别人拉下来用命令行跑，立刻出问题。所以一定要重视这个问题，把它搞清楚，而不是等到线上事故再找原因。

4. 实测：如何快速确认 Spring Boot 启动时到底用的是哪个 JDK

4.1 在代码里打印运行时版本

最直接的办法，就是在启动类里加一句运行时 JVM 信息输出。不用引入任何额外依赖，Spring Boot 的CommandLineRunner或者ApplicationRunner都可以：

package com.example.demo; import org.springframework.boot.CommandLineRunner; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; @SpringBootApplication public class DemoApplication implements CommandLineRunner { public static void main(String[] args) { SpringApplication.run(DemoApplication.class, args); } @Override public void run(String... args) throws Exception { System.out.println("=================== JVM 版本信息 ==================="); System.out.println("java.version: " + System.getProperty("java.version")); System.out.println("java.home: " + System.getProperty("java.home")); System.out.println("java.vendor: " + System.getProperty("java.vendor")); System.out.println("class.version: " + System.getProperty("java.class.version")); System.out.println("===================================================="); } }

启动后看到控制台打印的java.version是 17.0.1 还是 1.8.0_291，就一目了然了。这个方法是我在所有版本排查里最推荐的，因为它最直接，不会因为你看了错误的配置文件而误判。

java.home这个属性特别有用，它会打印出当前 JVM 实际的可执行文件所在目录。比如你在 IDEA 里启动，它会显示类似D:\Program Files\Java\jdk-17之类的路径；如果你在命令行启动，会显示C:\Program Files\Java\jdk1.8.0_291。这个路径是判断源头的最强证据，因为不管你怎么配置，这个值一定是 JVM 在启动时基于自身位置固定的，骗不了人。

4.2 查看启动时的 JVM 参数和 Dubug 输出

如果你不想改代码，也可以在控制台里观察日志。Spring Boot 启动时会打印很多信息，其中 Banner 的上方通常会有一行 Hibernate 或者 Tomcat 的提示，但不会直接告诉你 JDK 版本。这时候可以回到 IDEA 的Run控制台，看顶部的服务列表（Services 窗口）或者 Run 窗口标题栏。

IDEA 的 Run 窗口右上角会显示当前运行进程的完整命令行，鼠标悬停在上面能看到类似C:\Program Files\Java\jdk-17\bin\java.exe这样的路径。这比看日志更快，因为只要你启动过一次，IDEA 就会把这个命令缓存下来。

另外还有一个技巧：在 Spring Boot 的启动日志里，Tomcat 的启动信息会显示Java HotSpot(TM) 64-Bit Server VM和它的版本号，但不同版本的 Tomcat 打印的位置不一样，不如直接看进程命令行来得直观。

4.3 一次性看清：IDEA 里的多处 JDK 配置对照

我把 IDEA 里所有跟 JDK 相关的关键配置点整理成一个清单，方便你逐项核对：

这个对照表每次排查版本问题时，我都会按顺序过一遍。经常发生的情况是：Project SDK 已经改成了 8，但 Modules 层面还锁着 17，启动时依然用 17。IDEA 的 Module SDK 其实是最容易被忽略的一个层级，因为它在 Project Structure 里藏得比较深，而且 UI 上不是特别显眼。

5. 最实用的解法：怎么让项目在 IDEA 和命令行的启动版本保持统一

5.1 优先级最高：确定你到底想用哪个版本作为目标

在动手改配置之前，先想清楚一个问题：你的项目应该跑在哪个 Java 版本上？这个不由个人喜好决定，而是由项目的依赖版本、框架要求和部署环境共同决定。

如果你用的 Spring Boot 2.x（2.5 到 2.7 区间），官方支持到 Java 8/11/17 不等，但大多数生产环境是 Java 8 或者 11。如果你的 Spring Boot 是 3.x，那最低要求就是 Java 17，因为 Spring Framework 6 已经强制要求 Java 17 基础了。这种情况下如果你还在系统里配着 JDK 8，无论 IDEA 里怎么折腾，命令行 Maven 那一环一定跑不起来。

所以第一步是回去看一眼你的pom.xml里的spring-boot-starter-parent版本。如果<version>是 2.7.x 以下，目标跑 8 是安全的；如果已经是 3.0.x 以上，那目标应该定为 17，同时把系统环境变量里的JAVA_HOME改成 17。

5.2 统一 IDEA 内部的三处配置

当你确定了目标版本之后，把 IDEA 里的三处关键配置统一改成同一个版本：

1. Project SDK：File → Project Structure → Project → Project SDK，选择目标版本的 JDK。
2. Module SDK：File → Project Structure → Modules → 选中模块 → Dependencies → Module SDK，改成同一个版本。
3. Maven Runner JRE：Settings → Build Tools → Maven → Runner → JRE，选择目标版本的 JDK。

这三处统一之后，IDEA 内部无论是点 Run 还是通过 Maven 面板跑spring-boot:run，都会使用同一个版本。

这里要注意的是，如果你用了多个 Module，每个 Module 的 SDK 都要检查一遍。Module SDK 的优先级高于 Project SDK，很多人改了 Project 没改 Module，导致启动时还是旧版本，很容易产生“为什么我明明改对了却没生效”的错觉。

5.3 命令行那一侧：环境变量的硬切换

如果你还需要通过命令行（比如部署脚本、CI/CD、打包环境）来启动项目，那就必须把JAVA_HOME和PATH也切换到目标版本。这里我建议用工具而不是手动改系统环境变量，因为手动改太容易出错，而且切换成本高。

Windows 上可以安装 [JDK 版本管理工具]，Linux/macOS 上可以用 [替代工具]，把多个 JDK 纳入管理，然后按项目目录自动切换。至于具体工具，我个人在某次项目中用过免费的版本管理方案，后来发现其实系统自带的update-alternatives（Linux）也够用，只是每次切要敲一堆命令，不如写个小脚本一键切换方便。

这里分享一个临时脚本的写法，假设你在 Linux 上/opt/jdk8和/opt/jdk17两个目录下分别装了两个 JDK：

#!/bin/bash # switch-jdk.sh 版本切换小脚本 # 用法: source switch-jdk.sh 8 或 source switch-jdk.sh 17 if [ "$1" = "8" ]; then export JAVA_HOME=/opt/jdk8 elif [ "$1" = "17" ]; then export JAVA_HOME=/opt/jdk17 else echo "Usage: source switch-jdk.sh {8|17}" return 1 fi export PATH=$JAVA_HOME/bin:$PATH java -version

这个脚本的思路是把 JDK 安装路径按版本归类放在固定目录，切换时只改环境变量。source执行是为了让环境变量在当前终端生效，不是子进程里的临时生效。你可以在.bashrc或.zshrc里定义几个 alias，平时都不用管环境变量，切换时敲一行命令就完成。

5.4 把maven-compiler-plugin和 Spring Boot 的版本要求对齐

在确保 JDK 环境统一的同时，pom.xml里也要做到与 JDK 版本对齐，否则编译期照样出问题。一个典型的配置：

<properties> <java.version>17</java.version> <maven.compiler.source>17</maven.compiler.source> <maven.compiler.target>17</maven.compiler.target> </properties>

设置java.version是 Spring Boot 官方文档推荐的方式，它会通过父 POM 传播到maven-compiler-plugin和spring-boot-maven-plugin，让编译和运行都基于同一个版本。maven.compiler.source和maven.compiler.target是 Maven 编译器插件的旧式属性，新的版本推荐用<maven.compiler.release>，它比source/target更安全，不会因为source和target不一致导致运行时错误。

<properties> <java.version>17</java.version> <maven.compiler.release>17</maven.compiler.release> </properties>

release参数的好处是同时设置了 source、target 和 bootclasspath，统一了编译层面的所有细节。这个配置配合统一的 JDK 环境，基本能避免编译期和运行期的版本分裂。

6. 常见报错速查：版本不一致时的典型症状和解法

6.1UnsupportedClassVersionError——最典型的版本不匹配报错

这个报错出现的场景是：代码编译成了高版本 class 文件，但运行时用的是低版本 JVM。比如编译用的 JDK 17，运行用的是 JDK 8，抛出的异常长这样：

java.lang.UnsupportedClassVersionError: org/springframework/boot/SpringApplication 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

class file version 61.0对应的是 Java 17，52.0对应的是 Java 8。所以这句报错的翻译就是：代码是用 17 编译的，但你的运行环境只有 8，跑不动。

解法很简单：要么把运行环境升到 17，要么把编译版本降到 8。但要注意，降编译版本并不总是可行——如果你的代码用了 Java 9+ 的新特性，比如var、模块化、新 API，降到 8 编译肯定报语法错误。所以在动手降级之前，先看看代码里有没有用到新语法。

6.2 “错误: 无效的源发行版：17” 或 “无效的目标发行版：17”

这个报错出现在编译期，基本是 Maven 的编译 JDK 版本低于 17 导致的。比如你在 IDEA 里 Project SDK 是 17，但 Maven Runner JRE 设置的是 8，那么 Maven 进程本身跑在 Java 8 上，编译器插件拿到的是 Java 8 的 Javac，你却在pom.xml里要求maven.compiler.release=17，Javac 8 根本不认识--release 17这个参数。

排查方法：先看报错前后 Maven 输出的 JDK 信息——很多 Maven 启动配置会打印Java version: 1.8.0_291，如果没有，就在mvn -version里确认当前 Maven 用的是什么 Java。在 IDEA 里确认的话，去Settings → Maven → Runner → JRE改掉。

6.3Caused by: java.lang.NoClassDefFoundError: javax/xml/bind/DatatypeFactory

这个报错是 Spring Boot 2.x 在 Java 11+ 上运行时最经典的兼容性问题。Java 8 里一大堆javax.xml.bind的类在 JDK 9 之后被移除了，如果项目依赖里没有显式引入jakarta.xml.bind-api或javax.xml.bind:jaxb-api，在 Java 11/17 上运行就会报这个错。

某些开发者遇到这个报错后第一反应是“把 Java 降回 8”，这是个误解。正确做法是补上缺失的 JAXB 依赖，或者将项目升级到 Spring Boot 2.6+ 并使用 Jakarta EE 9+ 的命名空间。如果非要跑在 Java 8 上，那你得把 IDEA、Maven、环境变量全部切回 8，而不是只切一部分。

6.4 常见问题速查表

7. 背后的原理：为什么同一份代码会跑出两个版本

7.1 JVM 的查找路径和 classpath 的本质

要彻底理解这个问题，得回到 JVM 启动的基本原理。任何 Java 程序要运行，必须先有一个java可执行文件被系统找到并调用。这个java文件的位置，决定了后续所有类库的加载行为。而 IDE 做的事情，本质上只是在启动这个可执行文件之前，把运行参数（classpath、主类、系统属性）拼好，然后 fork 出一个子进程。

IDEA 的 Project SDK 概念，其实就是为 IDE 内部的各种操作提供一份 JDK 元数据：它知道 JDK 的bin/java在哪、lib/modules在哪、类库结构是什么样。当开始启动程序时，Project SDK 的java路径就直接被用作子进程的可执行文件。这个过程完全绕过了系统环境变量，因为操作系统不需要再去寻找java命令了——IDEA 直接把完整的路径传给了子进程。

所以你可以这样理解：系统的JAVA_HOME是给操作系统用的名片，让那些“不知道 Java 在哪”的脚本去查；而 IDEA 的 Project SDK 是给 IDEA 用的地址簿，IDE 自己心里有数，压根不需要查名片。这就解释了为什么你在系统层面怎么改，IDEA 里的程序依然我行我素。

7.2Class文件版本与 JVM 版本的关系

Java 的跨版本兼容机制是向后兼容的：高版本 JVM 能运行低版本编译出来的 class 文件，但低版本 JVM 不能运行高版本的 class 文件。这就像新版播放器能放老视频，但老播放器播不了新格式。

每个 class 文件的开头都有major_version，它决定了这个文件能被哪个版本的 JVM 识别：

当 JVM 加载 class 时，会先检查这个 major version，如果比自己支持的版本高，直接抛出UnsupportedClassVersionError。这就是版本不匹配报错的最底层原因。

7.3 Spring Boot 的自动配置和 JDK 版本的“软依赖”

Spring Boot 本身并没有强制绑定某个 JDK 版本，它只是一个依赖框架，但它的底层依赖——尤其是 Tomcat 和 Spring Framework——会对 JDK 版本有一些“软依赖”。例如 Spring Boot 2.7 支持 Java 8 到 Java 19，但如果你用 JDK 17，某些旧版本的 Tomcat 和 ASM 库可能需要升级，否则会报 ASM 版本不支持的错误。

这个“软依赖”带来的问题是：同一个 Spring Boot 版本，在不同的 JDK 上跑，可能需要不同版本的第三方依赖组合。你在 IDE 里用 JDK 17 跑起来没问题，部署到 JDK 8 环境后可能因为字节码增强（比如 CGLIB、ASM）和 JVM 内部实现差异，出现启动失败或类加载异常。

这就是为什么我强烈建议团队项目在场外统一 JDK 版本，而不是在本地随意切来切去。版本不一致带来的隐性成本，远比多装一个 JDK 的可移植性大得多。

8. 工具选型：多 JDK 环境下的日常管理方案

8.1 JDK 管理工具的选型思路

如果你的机器上同时安装了 JDK 8、11、17、21，手动配置环境变量显然不现实。我见过很多开发者因为图省事，只留一个 JDK 在系统里，需要其他版本时再装再删，结果时间都耗在安装配置上了。这里我推荐两个思路：一是操作系统自带的工具，二是专门的 JDK 版本管理工具。

在 Linux 上，update-alternatives是原生方案，但它只切换/usr/bin/java的软链接，不会自动修改JAVA_HOME。如果你用 Maven、Gradle 这些读取JAVA_HOME的工具，仅靠update-alternatives是不完整的。比较省事的是写一组 alias，或者干脆用轻量级的版本管理脚本，前文已经给出了示例。

Windows 上推荐用 [某种 JDK 切换工具]，它能从系统层面管理 JAVA_HOME 和 PATH，切换时对系统所有工具链生效。这个工具特别适合那些需要同时维护多个项目的开发者，比如一个项目要求 JDK 8，另一个要求 JDK 17。

8.2 针对本机多版本的实际管理方案

我自己的本机目前装了 JDK 8、11、17 三个版本，但我很少去手动改全局环境变量。我的做法是：全局JAVA_HOME固定在 JDK 17，因为这是大部分新项目的默认目标；需要 JDK 8 时，在 IDEA 里把对应项目的 Project SDK 单独切到 8，同时确认 Maven Runner JRE 和 Run Configuration 也指向 8。

这样做的核心逻辑是：IDEA 内的项目级配置粒度细、切换成本低，不用动系统级的东西；全局环境变量保持一个“默认值”，给命令行工具一个稳妥的兜底。如果你非要全局固定 8，而 IDEA 里跑 17 的新项目，那每次打开 IDEA 都会发现 Maven 导链时用的 JDK 不对，编译报错，体验很糟。

有个细节：如果全局JAVA_HOME是 17，而项目需要 JDK 8 的 Maven 命令行操作，直接在项目目录里跑mvn会报编译错误，因为 Maven 的脚本读取JAVA_HOME是 17。这时两个选择：要么配.mvn目录下的mavenrc文件（Maven 3.9+ 支持），要么给项目单独包一层启动脚本。截止到目前，.mvn/mavenrc这个功能在 Windows 上用起来还行，它会在这个目录下执行一段脚本，里面可以临时导出JAVA_HOME。

8.3 团队协作时的统一约定

比本机管理更重要的是团队内部的约定。我建议每个 Spring Boot 项目在仓库根目录放一个README.md，注明以下信息：

• 项目要求的 JDK 最低版本和推荐版本
• 是否必须使用某个特定版本（比如 JDK 17，因为 Spring Boot 3）
• 在 IDEA 中推荐的三处配置截图指引
• 命令行启动时的环境变量参考
• 常见报错和解决链接

这样即使团队里有人第一次接触项目，也能避免在错误版本上浪费半天时间。实际管理中我还喜欢在pom.xml里加上 Maven Enforcer 插件，强制要求构建环境的 JDK 版本，不合格直接拒绝编译：

<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-enforcer-plugin</artifactId> <version>3.4.1</version> <executions> <execution> <id>enforce-java</id> <goals> <goal>enforce</goal> </goals> <configuration> <rules> <requireJavaVersion> <version>[17,)</version> </requireJavaVersion> </rules> </configuration> </execution> </executions> </plugin>

这段配置的意思是：Maven 编译时必须运行在 Java 17 或更高版本，否则构建直接失败。这个机制比任何文档都管用，因为它把约束写进了构建流程本身，让“用错 JDK”的行为在一开始就被拦截。

9. 最后再分享一个排查小技巧

如果在某次启动时发现 IDEA 里面点 Run 用的版本和你预期不一致，最大嫌疑永远是 Run Configuration 里的 JRE 选项和 Module SDK。这两个地方最容易在 IDE 自动检测、或者你来回切换 JDK 时被无意识改掉。

排查顺序我建议按这个来：

1. 看启动类代码里打印的java.version，确认实际运行时版本。
2. 点开 Run → Edit Configurations，确认 JRE 区域是否为Default (Project SDK)。
3. 检查 Project Structure → Modules 里的 SDK 版本。
4. 检查 Project Structure → Project 里的 Project SDK。
5. 最后看 Maven Runner JRE 和 Importing JDK。

这个顺序从“结果”倒推到“配置”，速度最快。因为第 1 步一旦确认实际版本，后面几步只需要找哪个配置跟它匹配即可。

对于 Spring Boot 项目来说，版本分裂导致的问题往往非常隐蔽——它不一定立刻报错，而是可能在 JSP 编译、DevTools 热部署、某些反射库加载时才出幺蛾子。把这些配置彻底搞清楚，真的能省下不少排查时间。