quarkus cli 在 dev 模式下因未正确识别 jdk 17 而抛出 unsupportedclassversionerror（class file version 61.0 vs 55.0），本质是其启动脚本绕过系统 $path，优先依赖 java_home 或 macos 的 /usr/libexec/java_home 自动探测机制，导致实际调用 java 11 而非项目配置的 jdk 17。
quarkus cli 在 dev 模式下因未正确识别 jdk 17 而抛出 unsupportedclassversionerror（class file version 61.0 vs 55.0），本质是其启动脚本绕过系统 $path，优先依赖 java_home 或 macos 的 /usr/libexec/java_home 自动探测机制，导致实际调用 java 11 而非项目配置的 jdk 17。
一、问题根源：CLI 启动逻辑与 Maven 的根本差异
Quarkus CLI（尤其是 Homebrew 安装版本）不复用 Maven 的 JDK 配置，而是通过独立 Shell 脚本解析本地 Java 环境：
- ✅ Maven 命令（如 mvn quarkus:dev）：完全遵循 pom.xml 中 <maven.compiler.source> 和 <maven.compiler.target>，并受 JAVA_HOME 和 mvn -v 输出的 JDK 版本约束；
- ❌ Quarkus CLI（如 quarkus dev）：执行时忽略 pom.xml 和 Maven 配置，直接调用底层 java 命令——但该命令由 CLI 自带的启动脚本决定，其查找顺序为：
- 若 JAVA_HOME 已设置 → 使用 $JAVA_HOME/bin/java；
- 若未设置 JAVA_HOME（macOS）→ 执行 /usr/libexec/java_home 获取默认 JDK（常为系统预装的 Java 11）；
- 否则回退至 which java（可能指向旧版 JDK）。
上述日志中 class file version 61.0（JDK 17）与 up to 55.0（JDK 11）的冲突，正是因 CLI 运行时加载了 JDK 11 的 JVM，却试图加载由 JDK 17 编译的 Quarkus 扩展类（如 CamelHotReplacementSetup）所致。
二、精准解决方案：强制 CLI 使用 JDK 17
✅ 方案 1：显式设置 JAVA_HOME（推荐，全局生效）
在终端会话中执行（Linux/macOS）：
export JAVA_HOME=$(/usr/libexec/java_home -v 17) # macOS # 或（Linux/通用）： export JAVA_HOME=/usr/lib/jvm/jdk-17.0.3+7 # 替换为你的 JDK 17 实际路径
验证：
立即学习“Java免费学习笔记（深入）”；
echo $JAVA_HOME $JAVA_HOME/bin/java -version # 应输出 "17.x.x"
⚠️ 注意：若使用 Zsh/Bash，请将 export 添加到 ~/.zshrc 或 ~/.bashrc 并执行 source ~/.zshrc。
夸克扫描王 - 转Office Alibaba-Quark-Transoffice下载由夸克扫描王提供的文件格式转换工具。当用户需要将图片、截图或扫描件转换为 Office 文档（Word/Excel）或 PDF 时，使用此技能。适用于包含复杂表格、合同或图文混排内容的图片或扫描件，可尽量还原原始版式并生成可编辑文档。即使用户未明确提到格式转换，只要用户的需求涉及将图片内容转换为可编辑文档（如 .docx、.xlsx 或 .pdf），也应触发此技能。请勿用于提取纯文本或识别文字内容、图像增强处理或从零创建文档
✅ 方案 2：为 CLI 指定 Java 路径（临时覆盖）
直接调用 CLI 时传入 JAVA_HOME：
JAVA_HOME=$(dirname $(dirname $(readlink -f $(which java)))) quarkus dev # 或更可靠的方式（macOS）： JAVA_HOME=$(/usr/libexec/java_home -v 17) quarkus dev
✅ 方案 3：Homebrew 用户专属修复（macOS）
Homebrew 安装的 CLI 依赖 java_home 工具。运行以下命令强制将 JDK 17 设为系统默认：
sudo ln -sf /Library/Java/JavaVirtualMachines/jdk-17.0.3.jdk/Contents/Home /Library/Java/Home # 或使用 java_home 切换（需重启终端）： /usr/libexec/java_home -V # 查看已安装 JDK 列表 export JAVA_HOME=$(/usr/libexec/java_home -v 17)
三、关键注意事项与最佳实践
| 场景 | 推荐做法 | 说明 |
|---|---|---|
| 多 JDK 共存环境 | 使用 JAVA_HOME + export 切换，而非修改系统 PATH | 避免污染全局环境，且 CLI 脚本明确优先读取 JAVA_HOME |
| CI/CD 流水线 | 在构建步骤前显式声明 JAVA_HOME | 如 GitHub Actions 中添加 env: JAVA_HOME: /opt/java/openjdk-17 |
| IDE 集成（IntelliJ） | 保持 Project SDK 与 Module Language Level 均设为 17 | IDE 内置 Maven 和 Runner 自动继承此配置，但 CLI 仍需单独处理 |
| Docker 构建一致性 | 在 Dockerfile 中显式指定 JAVA_HOME 和 PATH | 例： ENV JAVA_HOME=/opt/java/openjdk-17 ENV PATH=$JAVA_HOME/bin:$PATH |
四、验证与收尾
执行以下命令确认 CLI 已使用正确 JDK：
# 检查 CLI 调用的 Java 版本 quarkus --version # 输出应包含 JDK 17 信息（部分版本会显示） # 或强制触发 JVM 信息打印 JAVA_HOME=$(/usr/libexec/java_home -v 17) quarkus dev --info 2>&1 | grep "Running on Java"
成功输出类似：
Running on Java 17.0.3+7-LTS (build 17.0.3+7-LTS, mixed mode, sharing)
? 延伸提示：Quarkus CLI 的设计初衷是轻量快速启动，因此刻意解耦于构建工具链。这也意味着——永远不要假设 CLI 与 Maven 共享同一 JDK 环境。生产级项目建议统一使用 mvn quarkus:dev 代替 CLI，既保证环境一致性，又可复用 pom.xml 中所有插件和 profile 配置。
至此，Quarkus CLI 将严格遵循 JDK 17 运行时契约，彻底解决 UnsupportedClassVersionError，让热重载（Dev Mode）与测试（quarkus test）回归稳定高效。
