优先选 eclipse-temurin:11-jre-slim-bullseye 或 mcr.microsoft.com/openjdk/jdk:11-ubuntu，因 openjdk:11-jre-slim 已弃用，无安全更新、基础系统 eol、无镜像签名；前者兼容性强、体积小，后者对 native 库更友好但略大；生产环境必须用 jre 标签并锁定具体版本号。
直接结论：优先选 eclipse-temurin:11-jre-slim-bullseye 或 mcr.microsoft.com/openjdk/jdk:11-ubuntu，别再用已弃用的 openjdk 官方镜像。
为什么不能继续用 openjdk:11-jre-slim？
官方 library/openjdk 镜像已于 2025 年底正式弃用，仅保留早期预览版（Early Access）更新。这意味着：
- 安全补丁不再同步推送，
openjdk:11-jre-slim可能长期停留在含已知 CVE 的旧版本上 - 基础 OS（如
stretch、buster）已 EOL，apt 源不可用，RUN 指令可能构建失败 - 镜像层无签名验证，CI 流水线中拉取时容易因校验失败中断
eclipse-temurin 和 microsoft/openjdk 哪个更稳？
两者都是生产就绪的 OpenJDK 替代方案，但适用场景略有差异：
-
eclipse-temurin:11-jre-slim-bullseye：基于 Debian 11（bullseye），包生态成熟，兼容绝大多数 Java 应用；-slim已移除 GUI 相关组件，体积约 120MB，适合通用服务部署 -
mcr.microsoft.com/openjdk/jdk:11-ubuntu：基于 Ubuntu 22.04，glibc 版本较新，对 JNI 调用或依赖系统库的组件（如某些加密/压缩 native 库）更友好；但体积略大（约 180MB），且默认是jdk（含javac），若只运行 JAR，建议改用11-jre-ubuntu - 如果项目用到 Arthas、jstack 等诊断工具，
eclipse-temurin的jre版本仍包含jcmd、jstat，无需额外安装 JDK
alpine 镜像真那么小又安全？
别盲目追小。用 eclipse-temurin:11-jre-alpine 前必须确认：
- 你的应用是否调用任何依赖 glibc 的 native 库（比如某些 JDBC 驱动、Netty 的 epoll transport、Log4j 的 JNDI lookup）—— Alpine 用 musl libc，这类调用会直接报
NoClassDefFoundError或UnsatisfiedLinkError -
java -version在 Alpine 上输出的 JVM 名称是OpenJDK Runtime Environment (build 11.0.22+7)，但底层线程模型、信号处理行为与 glibc 环境存在细微差异，高并发 GC 场景下偶发卡顿 - 调试困难：Alpine 默认不带
bash、strace、lsof，容器进不去、问题复现不了时只能换镜像重试
JDK 还是 JRE？这个问题没商量
生产环境一律用 jre 标签，除非你明确需要在容器里编译代码（CI 构建阶段除外）：
- JDK 镜像多出
javac、javadoc、jconsole等二进制，不仅增大体积（+60~90MB），还扩大攻击面——历史上jconsole远程连接漏洞曾被用于 RCE - 部分安全扫描工具（如 Trivy、Clair）会将 JDK 中的
keytool、rmiregistry列为高风险组件，触发合规告警 - 如果你用多阶段构建，编译阶段用
eclipse-temurin:11-jdk-slim-bullseye，运行阶段 COPY JAR 后 base oneclipse-temurin:11-jre-slim-bullseye，这是最干净的路径
最容易被忽略的一点：所有镜像标签必须锁定具体版本号，例如 eclipse-temurin:11.0.22_7-jre-slim-bullseye，而不是 11-jre-slim-bullseye。后者看似方便，实则每次 docker build 都可能拉到不同 patch 版本，导致某天凌晨上线后 JVM 行为突变——比如 GC 日志格式微调、ZGC 默认参数变更，监控告警全崩。
