问题现象
在开发 Spring AI Alibaba 项目时，用 VSCode 打开项目后，发现 IDE 将项目的 JDK 版本识别为默认版本（如 1.8），而非 pom.xml 中配置的 Java 17。具体表现为：
record、sealed class等 Java 17 语法特性全部报红- IDE 提示不支持的语言级别
- 但命令行
mvn compile完全正常，编译通过
问题定位
pom.xml 中明明配置了：
<properties>
<java.version>17</java.version>
<maven.compiler.source>${java.version}</maven.compiler.source>
<maven.compiler.target>${java.version}</maven.compiler.target>
</properties>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>${maven-compiler-plugin.version}</version>
<configuration>
<release>${java.version}</release>
<source>${java.version}</source>
<target>${java.version}</target>
</configuration>
</plugin>
配置没有问题，命令行也能正常编译，那问题出在哪？
逐段排查后，锁定了 maven-compiler-plugin 中的这段 <executions> 配置：
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>${maven-compiler-plugin.version}</version>
<configuration>
<release>${java.version}</release>
<compilerArgs>
<compilerArg>-parameters</compilerArg>
</compilerArgs>
</configuration>
<executions>
<!-- Replacing default-compile as it is treated specially by Maven -->
<execution>
<id>default-compile</id>
<phase>none</phase> <!-- 这就是罪魁祸首 -->
</execution>
<!-- Replacing default-testCompile as it is treated specially by Maven -->
<execution>
<id>default-testCompile</id>
<phase>none</phase>
</execution>
<execution>
<id>java-compile</id>
<goals>
<goal>compile</goal>
</goals>
<phase>compile</phase>
</execution>
<execution>
<id>java-test-compile</id>
<goals>
<goal>testCompile</goal>
</goals>
<phase>test-compile</phase>
</execution>
</executions>
</plugin>
原因分析
为什么官方要写 <phase>none</phase>
这是 Maven 中的一个经典技巧。maven-compiler-plugin 的 default-compile 是 Maven 内置的特殊执行，不能直接修改其配置。当你需要给编译器添加额外参数（如 Error Prone 插件）时，必须：
- 先用
<phase>none</phase>禁用默认的default-compile和default-testCompile - 再定义自定义执行
java-compile和java-test-compile来替代，在新执行中传入额外的compilerArgs
这种做法在命令行下完全正常——Maven 会跳过被禁用的默认执行，执行自定义执行，编译器配置从插件级别继承。
为什么 VSCode 识别不了
VSCode 的 Java 支持底层使用 Eclipse JDT Language Server (JDT.LS)，通过 M2E（Maven-to-Eclipse Integration） 解析 Maven 项目。M2E 的生命周期映射机制导致了信息断裂：
┌─────────────────────────────────────────────────────┐
│ M2E 的配置提取流程 │
├─────────────────────────────────────────────────────┤
│ │
│ 1. 扫描 maven-compiler-plugin 的活跃执行 │
│ ├── default-compile (phase=none) │
│ │ └→ 不活跃，跳过，不提取 JDK 配置 │
│ │ │
│ ├── java-compile (自定义 id) │
│ │ └→ M2E 只识别 default-compile / │
│ │ default-testCompile 两个标准 id， │
│ │ 不识别自定义执行，不提取 JDK 配置 │
│ │ │
│ └→ 结果：无法获取 source/target/release 信息 │
│ 回退到默认 JDK 版本（通常为 1.8） │
│ │
└─────────────────────────────────────────────────────┘
问题出在两层：
default-compile被禁用 → M2E 认为该执行不活跃，不再从中提取source/target/release配置- 自定义执行 id 不被识别 → M2E 对
maven-compiler-plugin有内建的特殊处理，只识别default-compile和default-testCompile两个标准执行 id，java-compile和java-test-compile不在识别范围内
虽然 <configuration> 写在插件级别，理论上所有执行都应继承，但 M2E 的实现优先从活跃的标准执行中读取配置，导致配置信息断裂。
为什么命令行不受影响
命令行 mvn compile 时，Maven 的执行逻辑与 M2E 完全不同：
Maven 构建流程:
default-compile (phase=none) → 跳过
java-compile (phase=compile) → 执行，继承插件级别配置 ✓
M2E 项目导入流程:
default-compile (phase=none) → 不活跃，不提取配置
java-compile (自定义 id) → 不识别，不提取配置
→ 回退到默认值 ✗
Maven 是"执行驱动"——只要执行就生效；M2E 是"配置提取驱动"——只有识别到的配置才生效。两者的信息通道不一致，就是这个 bug 的根源。
解决方案
注释掉 <executions> 块（我的选择）
这是最直接的方式。注释掉整个 <executions> 配置，让 M2E 从默认的 default-compile 中正常提取 JDK 配置：
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>${maven-compiler-plugin.version}</version>
<configuration>
<release>${java.version}</release>
<source>${java.version}</source>
<target>${java.version}</target>
<compilerArgs>
<arg>-parameters</arg>
<arg>-XDcompilePolicy=simple</arg>
<arg>-XDaddTypeAnnotationsToSymbol=true</arg>
<arg>--should-stop=ifError=FLOW</arg>
<arg>-Xplugin:ErrorProne -XepDisableAllChecks -Xep:NullAway:ERROR -XepOpt:NullAway:OnlyNullMarked -XepOpt:NullAway:JSpecifyMode=true</arg>
</compilerArgs>
<annotationProcessorPaths>
<path>
<groupId>com.google.errorprone</groupId>
<artifactId>error_prone_core</artifactId>
<version>${error-prone.version}</version>
</path>
<path>
<groupId>com.uber.nullaway</groupId>
<artifactId>nullaway</artifactId>
<version>${nullaway.version}</version>
</path>
<path>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-configuration-processor</artifactId>
</path>
</annotationProcessorPaths>
</configuration>
</plugin>
优点：简单直接，VSCode 能正确识别 JDK 版本
代价：Error Prone 等自定义编译参数在 IDE 中不会生效（但不影响命令行构建）
❌ 不可行的方案：VSCode 设置指定 JDK
一个容易想到的思路是在 VSCode 的 settings.json 中配置 JDK 运行时：
{
"java.configuration.runtimes": [
{
"name": "JavaSE-17",
"path": "C:/Program Files/Java/jdk-17",
"default": true
}
]
}
这个方案不可行。 原因是 java.configuration.runtimes 控制的是：
- JDT.LS 自身用哪个 JDK 启动
- 项目的运行时 classpath 指向哪个 JDK
但它不能覆盖 M2E 从 pom.xml 解析出的编译器合规级别(compiler compliance level)。即使指定了 JDK 17 运行时，项目的语言级别仍然是 M2E 解析出来的默认值（1.5），Java 17 的语法特性依然报红。
这是两个不同的概念：
| 概念 | 控制什么 | 由谁决定 |
|---|---|---|
| JDK 运行时 | 项目运行时用哪个 JDK | java.configuration.runtimes |
| 编译器合规级别 | 编辑器中允许使用哪些语法特性 | M2E 从 maven-compiler-plugin 配置中提取 |
