Linux不同发行版安装OpenJDK本质一致，仅包名和仓库源不同：RHEL系用dnf install java-17-openjdk-devel，Ubuntu/Debian用apt install openjdk-17-jdk；换厂商版本需先添加对应源，命令逻辑不变。
Linux包管理器安装：发行版差异只在包名，不在于命令逻辑
在CentOS/RHEL、Ubuntu/Debian或openEuler这类有成熟仓库的系统上，不同OpenJDK发行版的安装方式**本质一致**，区别仅体现在包名命名规则和仓库源配置上。
比如你执行 dnf install java-17-openjdk-devel，实际装的是系统默认仓库提供的OpenJDK 17（通常是Red Hat或Eclipse Temurin构建）；而想装Amazon Corretto，就得先手动添加Corretto的YUM源，再运行 dnf install corretto-17-java-devel。包名变了，但dnf install这个动作没变。
- openEuler/AlmaLinux/RHEL系：默认仓库通常只提供
java-17-openjdk-devel（即上游OpenJDK构建），不带厂商前缀 - Ubuntu/Debian：包名是
openjdk-17-jdk，来源是Debian官方维护的OpenJDK二进制 - 想用Temurin或Zulu？必须先导入对应APT/YUM源，否则
apt search temurin根本搜不到
Windows/macOS直接安装包：发行版差异体现在安装器行为和默认路径
Windows上用MSI、macOS用PKG安装时，不同发行版的体验差异最明显——不是功能差别，而是“装完在哪”“PATH加没加”“注册表/launchd配没配”这些细节。
Eclipse Temurin的MSI安装包会主动勾选“Add to PATH”，而Azul Zulu的安装器默认不勾；Amazon Corretto在macOS上会把JDK装到/usr/lib/jvm/zulu-17-amd64，Temurin则习惯用/Library/Java/JavaVirtualMachines/temurin-17.jdk。这些路径差异直接影响java -version能否命中，也决定IDE（如IntelliJ）能不能自动扫描到它。
- 安装后务必检查
which java和java -version输出的路径是否匹配预期安装位置 - Temurin和Microsoft Build的安装器在Windows上会写注册表项
HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Development Kit，但Zulu和Corretto通常不写——这意味着某些老工具（如旧版Android Studio）可能识别不到 - macOS用户注意：
/usr/lib/jvm是Linux惯用路径，macOS原生不创建该目录；强行软链过去可能导致update-alternatives类工具失效
手动解压tar.gz安装：所有发行版行为完全一致，但JDK结构有隐性差异
下载temurin-17.0.2+8-jdk-x64-linux.tar.gz、zulu17.42.17-ca-jdk17.0.2-linux_x64.tar.gz或corretto-17.0.2.8.1-linux-x64.tar.gz，解压后都遵循标准JDK目录结构：bin/下有java、javac，lib/下有modules等。表面看没区别，但实际有两点容易踩坑：
-
java -XshowSettings:properties -version输出里，java.home指向的路径必须是解压后的根目录（比如/opt/jdk-17-temurin），不能是/opt/jdk-17-temurin/jre——后者是JRE子目录，会导致javac找不到tools.jar（虽然JDK 9+已模块化，但部分构建脚本仍硬编码依赖该路径） - Amazon Corretto和Microsoft Build默认启用JFR（Java Flight Recorder），Temurin需额外加
-XX:+FlightRecorder参数；这不会影响安装，但会影响后续监控工具调用 - 所有发行版的
bin/java都是shell脚本封装，不是直接可执行二进制——所以别用file bin/java去判断是否“真安装成功”，要看java -version能否正常输出且不报Unable to load native library
JDK版本与发行版的兼容性陷阱：不是所有17都叫JDK 17
表面上都是JDK 17，但不同发行版对JEP（JDK Enhancement Proposal）的支持节奏不同。例如JEP 405（记录模式）在JDK 17中只是预览特性，Temurin 17.0.2默认关闭，而Zulu 17.32+已默认启用；又比如JEP 412（外部函数与内存API）在Corretto 17.0.6才完整支持，早于它的版本会抛UnsupportedOperationException。
这不是bug，是各发行版基于自身测试策略做的开关控制。所以当你看到java -version显示17.0.2+8，不能默认认为所有JDK 17特性都就绪。
- 查当前JDK支持哪些预览特性：
java --enable-preview -version如果报错，说明该发行版禁用了预览模式 - 验证JFR是否可用：
java -XX:+FlightRecorder -XX:StartFlightRecording=duration=60s,filename=recording.jfr -version，失败则要换发行版或升级小版本 - Spring Boot 3.2+要求JDK 17.0.6+，但不是所有发行版都同步更新了小版本号——Temurin 17.0.2和Corretto 17.0.2可能都满足语法兼容，但只有后者内置了Spring所需的TLS 1.3握手修复补丁
真正麻烦的从来不是“怎么装”，而是装完之后你以为它就是个标准JDK 17，结果在CI流水线里跑测试时，某个发行版特有的JVM参数被静默忽略，或者某条javac --release 17编译出来的class，在另一发行版的JVM上加载失败——这种差异藏在构建日志深处，得靠java -XshowSettings:vm逐项比对才能揪出来。
