优先选 OpenJDK 官方镜像（如 openjdk:17-jre-slim 或 openjdk:17-jdk-slim），Oracle JDK 已弃用且许可协议导致构建失败；官方镜像已预设 JAVA_HOME 和 PATH，无需手动设置；多阶段构建可最小化运行时镜像体积。
docker build 时 JDK 版本选 OpenJDK 还是 Oracle JDK？
优先选 OpenJDK，尤其是带 -jre 或 -jdk 后缀的官方镜像。Oracle JDK 在 Docker Hub 官方镜像中已弃用（自 2021 年起），且需手动接受许可协议，docker build 无法交互确认，直接失败。
常见错误现象：The command '/bin/sh -c apt-get install -y oracle-java8-installer' returned a non-zero code: 1 —— 就是因为许可协议阻断了自动化构建。
-
openjdk:17-jre-slim：生产推荐，体积小、无冗余工具，适合 Spring Boot 等只运行不编译的场景 -
openjdk:17-jdk-slim：开发/编译型服务必需，含javac、jdeps等工具 - 避免用
openjdk:latest：指向不稳定快照版，CI/CD 中易导致构建结果漂移
Dockerfile 中如何正确设置 JAVA_HOME 和 PATH？
不用手动写 export JAVA_HOME=...，OpenJDK 官方镜像已预设好环境变量。你只需验证是否生效，而非覆盖它。
典型错误：在 Dockerfile 里重复声明 ENV JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64 —— 路径硬编码，不同架构（ARM/amd64）或不同发行版（Debian/Alpine）下会失效。
- 官方镜像默认设置：
JAVA_HOME指向/usr/lib/jvm/default-jvm（符号链接），自动适配底层实际路径 - 检查方式：构建后运行
docker run <image> sh -c 'echo $JAVA_HOME'，应输出非空值 - 若需显式调用
java或javac，直接用命令名即可，PATH已包含$JAVA_HOME/bin
多阶段构建中 JDK 只在 build 阶段需要，怎么最小化最终镜像？
用多阶段构建把编译和运行分离：build 阶段装 openjdk:17-jdk-slim，runtime 阶段只 copy 编译产物 + openjdk:17-jre-slim。
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
示例关键片段：
FROM openjdk:17-jdk-slim AS builder WORKDIR /app COPY pom.xml . RUN mvn dependency:go-offline COPY src ./src RUN mvn package -DskipTests FROM openjdk:17-jre-slim COPY --from=builder /app/target/*.jar app.jar ENTRYPOINT ["java","-jar","app.jar"]
注意点：
- 不要在 runtime 阶段
RUN apt-get install补 JDK —— 这会让镜像体积翻倍（+200MB）且引入不必要的包管理器残留 - Alpine 基础镜像慎用：
openjdk:17-jre-alpine虽小，但 glibc 兼容性差，某些 JNI 库（如 Netty native、JNA）可能报Illegal instruction - Spring Boot 3.x 必须用 JDK 17+，若 base image 是
openjdk:11-jre-slim，启动直接失败并报错Unsupported class file major version 61
容器内 java -version 正确但应用启动报 NoClassDefFoundError？
大概率是 classpath 混乱或 jar 包未正确加载，不是 JDK 安装问题。容器里 java -version 成功只说明 JVM 可执行，不等于应用依赖就绪。
排查顺序：
- 进容器执行
ls -l /app/target/（或你指定的 jar 目录），确认目标 jar 存在且非空 - 运行
java -cp app.jar MainClass（替换为实际主类）看是否抛相同异常 —— 排除ENTRYPOINT写错参数 - 检查 jar 是否含完整依赖：Spring Boot 打包要用
mvn spring-boot:repackage，普通 jar 需maven-assembly-plugin合并依赖 - 留意日志里缺失的类名，反查它属于哪个 jar，再确认该 jar 是否被
COPY进镜像或打包进 fat jar
真正容易被忽略的是：JDK 安装本身几乎不会出错，出错的永远是“你以为它在跑 JDK，其实它在跑你漏掉的 classpath”。
