生产环境必须使用带完整小版本和构建号的Java镜像标签，如eclipse-temurin:17.0.2_8-jdk-focal，禁用openjdk:17-jdk等模糊标签，以防JVM行为变更、GC参数调整或安全补丁引发兼容性问题。
生产环境必须固定 Java 版本，否则 docker pull openjdk:17-jdk 这类不带具体小版本的标签会悄悄升级到新修订版，可能引入 JVM 行为变更、GC 参数默认值调整甚至安全补丁导致的兼容性断裂——比如某次 17.0.2 升级到 17.0.3 后，-XX:+UseZGC 在容器内存限制下触发提前 OOM，而日志里只显示 java.lang.OutOfMemoryError: Java heap space，根本看不出是 JVM 自身行为变化所致。
用完整语义化版本号替代模糊标签
官方 openjdk 镜像已弃用 latest 和纯主版本（如 17-jdk）作为生产推荐；Eclipse Temurin、Amazon Corretto 等主流发行版也明确要求使用带构建号的完整标签。
-
eclipse-temurin:17.0.2_8-jdk-focal✅ 明确到构建号，Ubuntu Focal 基础，JDK 完整工具链 -
amazoncorretto:21.0.2.13.1-amazonlinux2✅ Amazon Linux 2 + 具体 CVE 修复编号 -
openjdk:17-jdk-slim❌ 无小版本，下次docker pull可能拉到17.0.4 -
eclipse-temurin:17-jre-alpine❌ Alpine 变体未锁定 glibc/musl 兼容版本，17.0.1和17.0.2的 musl 支持有差异
避免依赖镜像仓库的 latest 重定向机制
Docker Hub 和部分私有仓库会对 latest 标签做自动重定向，但这个行为不可审计、不可回滚。更危险的是，某些镜像仓库（如旧版 Harbor）在同步上游时会把 17-jdk 自动映射成最新子版本，导致本地 docker images 显示的 IMAGE ID 和远程实际内容不一致。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 永远用
docker pull eclipse-temurin:21.0.6_7-jre-ubuntu-jammy，而不是docker pull eclipse-temurin:21-jre - CI/CD 流水线中禁止出现
FROM openjdk:17，应写死为FROM eclipse-temurin:17.0.2_8-jdk-focal - 用
docker inspect --format='{{.RepoDigests}}' <image-id>验证镜像是否具备可复现的 digest（如eclipse-temurin@sha256:abc123...），这才是真正防篡改的标识
验证 JAVA_HOME 和 java -version 输出是否匹配预期
即使用了完整标签，仍需在容器启动后验证实际运行的 JDK 是否符合预期——因为某些自定义 Dockerfile 可能覆盖了基础镜像的 JAVA_HOME，或通过 update-alternatives 切换过默认 Java。
立即学习“Java免费学习笔记（深入）”；
- 在
ENTRYPOINT或健康检查脚本中加入：java -version 2>&1 | head -n1和echo $JAVA_HOME - 检查
java -XshowSettings:properties -version 2>/dev/null | grep 'java.home\|java.version'，确认 JVM 实际加载路径和版本字符串一致 - 若发现
JAVA_HOME指向/usr/lib/jvm/java-17-openjdk-amd64但java -version输出却是17.0.3，说明系统级 Java 被意外覆盖，需在 Dockerfile 中显式ENV JAVA_HOME=/opt/java（Temurin 默认路径）
最易被忽略的一点：Java 版本固定 ≠ JVM 参数安全。固定了 17.0.2_8 后，仍要同步锁定 -XX:+UseContainerSupport、-XX:MaxRAMPercentage 等容器感知参数，否则同一镜像在不同内存限制下可能触发完全不同的 GC 行为——这不属于版本控制范畴，但常被当作“版本已固定”而漏掉。
