OpenJDK不管理依赖版本，真正锁定版本的是Maven的<dependencyManagement>或Gradle的enforcedPlatform；JDK仅影响运行环境与语言特性，与第三方库版本无关。

OpenJDK 本身不管理项目依赖版本——它只是运行环境；真正锁定依赖版本的是构建工具（如 Maven、Gradle）和依赖声明方式。 直接在 JDK 层面“固定依赖版本”不仅做不到，还会混淆运行时与构建时的职责边界。下面说清楚怎么做、为什么这么定、以及哪些地方一动就崩。

为什么 JAVA_HOME 改了，项目依赖版本却没变？

因为 JAVA_HOME 只影响 java、javac 等命令的执行版本，不影响 Maven 下载的 spring-core、logback-classic 这类第三方库。这些库的版本由项目配置文件控制，和你用 JDK 8 还是 JDK 21 无关（除非它们声明了 Java 版本兼容性约束）。

• 常见误解：以为换 JDK 就能“升级依赖”——实际只会触发编译报错或运行时 UnsupportedClassVersionError
• 真实影响：JDK 版本决定你能用哪些语言特性（如 record、sealed）、哪些 API（如 String.isEmpty() 在 JDK 6 不可用），但不决定你引入哪个 guava 版本
• 验证方式：执行 mvn dependency:tree | grep guava，看到的版本号和 JAVA_HOME 指向完全无关

Maven 中用 <dependencyManagement> 锁定版本

这是最常用也最可靠的锁定方式，尤其适合多模块项目。它不直接引入依赖，而是为子模块中声明的依赖“预设版本”，避免各模块各自指定导致冲突。

OpenJDK 24

下载

• 在根 pom.xml 的 <dependencyManagement> 块里统一写死版本：

  <properties>
    <spring.version>5.3.30</spring.version>
  </properties>
  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-context</artifactId>
        <version>${spring.version}</version>
      </dependency>
    </dependencies>
  </dependencyManagement>

• 子模块 pom.xml 中只写坐标，不写 <version>：

  <dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-context</artifactId>
  </dependency>

• 陷阱：如果子模块自己写了 <version>，会覆盖 <dependencyManagement> 的设定——这不是 bug，是 Maven 明确设计的行为

Gradle 中用 platform 或 enforcedPlatform 锁定 BOM

Gradle 推荐用 BOM（Bill of Materials）统一管理 Spring、Micrometer 等生态的依赖版本，比逐个写死更可持续。

• 在 build.gradle 中引入官方 BOM：

  dependencies {
    implementation platform('org.springframework.boot:spring-boot-dependencies:3.2.12')
    implementation 'org.springframework.boot:spring-boot-starter-web'
  }

• 用 enforcedPlatform 强制所有传递依赖服从该 BOM：

  dependencies {
    implementation enforcedPlatform('org.springframework.boot:spring-boot-dependencies:3.2.12')
    implementation 'com.fasterxml.jackson.core:jackson-databind'
  }

• 注意：BOM 本身不含代码，只提供版本元数据；若本地仓库缓存了旧版 BOM，执行 ./gradlew --refresh-dependencies 才能拉取最新版

为什么 mvn clean install 有时还是用了错误版本？

因为本地 ~/.m2/repository 缓存了旧构件，或父 POM 被其他继承链覆盖，或 IDE（如 IntelliJ）未同步 Maven 配置。

• 检查实际解析出的版本：运行 mvn dependency:resolve，看输出里 resolved version 是不是你期望的
• 强制清理缓存：删掉 ~/.m2/repository/org/springframework/ 对应路径，再重装（慎用于生产 CI）
• IDE 同步失败典型表现：Maven 视图显示版本正确，但运行时报 NoClassDefFoundError——此时右键项目 → Maven → Reload project 通常能解决
• 最隐蔽的坑：某个子模块的 pom.xml 里写了 <scope>import</scope> 引入另一个 BOM，它可能悄悄覆盖了你主 BOM 的版本策略

真正难的不是写对一行 <version>，而是在跨团队协作、CI 流水线、IDE 和命令行之间保持版本决策的一致性。一旦有人绕过 dependencyManagement 直接写死版本，或在 Gradle 里混用 platform 和手动 version，锁定就形同虚设。