关键不是装openjdk，而是让项目只认自己的jdk；需验证mvn -v、java -version及ide/插件显式指定的jdk三处，通过项目级环境变量或docker复制本地jdk实现精准隔离。
直接用系统全局 JDK 会污染其他项目，旧项目（尤其是 Java 8）必须隔离运行时和构建工具链。关键不是“装 OpenJDK”，而是“让这个项目只认它自己的 JDK”。
确认项目真实 JDK 需求
别只看 pom.xml 里的 <java.version>1.8</java.version> —— 这只是 Maven 编译目标，不等于运行时版本。实际要查三处：
-
mvn -v输出的 Java 版本（Maven 自身运行依赖） -
java -version在项目根目录下执行的结果（IDE 或 CI 实际调用的） -
spring-boot-maven-plugin的<jvmarguments></jvmarguments>或 IDE 的 Run Configuration 中显式指定的-Djava.home=...
很多“Java 8 项目跑在 JDK 17 上报错”，其实是 Maven 插件用了新 JVM 启动旧字节码，或 javax.* 包被移除导致 ClassNotFoundException。
Linux/macOS 下用独立 JDK 目录 + 环境变量隔离
不改系统 JAVA_HOME，只为当前项目生效：
- 下载对应平台的
openjdk-8u392-b08（LTS 最终版，2025 年仍受支持），解压到项目同级目录，例如：./jdk8/ - 在项目根目录新建
.env文件（或直接写进 shell alias）：export JAVA_HOME=$(pwd)/jdk8 export PATH=$JAVA_HOME/bin:$PATH
- 每次进入项目前执行：
source .env；验证：which java应返回./jdk8/bin/java
注意：IDEA/Eclipse 默认读取系统 JAVA_HOME，需在 File → Project Structure → Project → Project SDK 手动指向 ./jdk8，否则编辑器提示和编译仍可能用错版本。
Windows 下避免注册表干扰的实操方式
Windows 的 java.exe 常被系统路径或旧版 JRE 覆盖，setx 全局修改风险高：
- 不要用
setx JAVA_HOME，改用项目级批处理：setup-env.bat内容为：@echo off set JAVA_HOME=%~dp0jdk8 set PATH=%JAVA_HOME%\bin;%PATH% echo JDK 8 activated: %JAVA_HOME%
- 双击运行该 BAT，再启动 IDEA 或命令行（确保是同一个 CMD 窗口），
java -version就会锁定输出1.8.0_392 - 如果用 Git Bash，需额外在
.bashrc中判断路径：[[ "$PWD" == */my-legacy-project ]] && export JAVA_HOME="$(pwd)/jdk8"
常见坑：PowerShell 不继承 CMD 的环境变量，所以 start-process 启动的 IDEA 仍走系统默认 JDK —— 必须从同一 PowerShell 会话中用 .\idea.bat 启动。
Docker 构建时如何保持与本地一致
本地用 ./jdk8/，Dockerfile 却用 FROM openjdk:8-jdk-slim，镜像内路径是 /usr/lib/jvm/java-8-openjdk-amd64，二者不一致会导致本地调试通过、CI 失败。
- 方案一（推荐）：Dockerfile 显式复制本地 JDK：
COPY ./jdk8 /opt/java8 ENV JAVA_HOME=/opt/java8 ENV PATH=$JAVA_HOME/bin:$PATH
- 方案二：用
openjdk:8-jdk-slim，但本地也统一用该镜像启动开发容器：docker run -v $(pwd):/workspace -w /workspace -it openjdk:8-jdk-slim bash - 关键点：Maven
settings.xml中的<localrepository></localrepository>路径必须映射到宿主机，否则每次构建都重下依赖
最易忽略的是时区和字符集：OpenJDK 8 默认 file.encoding=ANSI_X3.4-1968（即 US-ASCII），中文路径或日志乱码时，要在 MAVEN_OPTS 或 Docker ENTRYPOINT 中加 -Dfile.encoding=UTF-8。
