答案是JDK架构不匹配与shell配置文件误用导致环境变量未生效。Intel/M系列Mac的JDK路径写法一致，但M系列必须用~/.zshrc而非~/.bash_profile，且需用/usr/libexec/java_home -arch arm64动态指定原生ARM64 JDK，否则java -version虽正常，mvn或IDE会因架构不兼容而静默失败。
Intel 和 M 系列 Mac 的 JDK 安装路径、环境变量写法本身没有本质差异，真正影响配置成败的是 JDK 架构类型与 shell 默认配置文件的组合问题。
为什么 java -version 显示正常但 mvn 或 IDE 仍报找不到 JDK？
常见于 Intel Mac 用户误装了 ARM64 JDK（或反之），或者环境变量没被当前 shell 加载。M 系列芯片若装了 x86_64 JDK，会依赖 Rosetta 2 转译——java -version 可能成功，但 Maven、Gradle 或某些 JNI 库会直接崩溃或静默失败。
- 用
uname -m确认架构：arm64是 M 系列，x86_64是 Intel - 用
/usr/libexec/java_home -V查看已注册 JDK 列表，注意每条路径末尾的架构标识（如jdk-17.0.2.jdk/Contents/Home下的Info.plist里有JVMCapabilities字段） - Intel Mac 上装 ARM64 JDK 会无法注册到
/usr/libexec/java_home，导致该命令不返回对应版本
~/.zshrc vs ~/.bash_profile：M1/M2/M3 必须用前者
macOS Catalina（10.15）起默认 shell 是 zsh，不是 bash。很多老教程教改 ~/.bash_profile，在 M 系列 Mac 上改了也无效——新开终端根本不会加载它。
- 确认当前 shell：
echo $SHELL，输出应为/bin/zsh - 环境变量必须写进
~/.zshrc（不是~/.zprofile，除非你明确需要登录时才加载） - 改完记得执行
source ~/.zshrc，否则当前终端不生效 - IDE 启动方式影响加载：从 Dock 或 Spotlight 启动的 IntelliJ/VS Code 不读
~/.zshrc，需通过终端命令open -a "IntelliJ IDEA"启动才能继承环境变量
JAVA_HOME 动态赋值比硬编码路径更可靠
硬写死路径如 export JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk-17.jdk/Contents/Home 看似简单，但换 JDK 版本、重装系统、或多人协作时极易出错。M 系列用户尤其要注意：ARM64 和 x86_64 JDK 的安装路径完全一样，仅靠路径无法区分架构。
- 推荐写法：
export JAVA_HOME=$(/usr/libexec/java_home -v 17)（自动匹配最新 17.x） - 指定架构更稳妥：
export JAVA_HOME=$(/usr/libexec/java_home -v 17 -arch arm64)（M 系列专用） - 若要支持多版本切换，定义别名时也必须带
-arch参数，例如：alias jdk17arm="export JAVA_HOME=$(/usr/libexec/java_home -v 17 -arch arm64) && java -version" - 注意：
/usr/libexec/java_home本身不校验架构兼容性，只按路径注册；它返回的 JDK 必须是当前芯片原生支持的，否则后续工具链会出问题
最容易被忽略的点：IDE 或构建工具（如 Gradle Wrapper）可能缓存旧的 JAVA_HOME，改完配置后不仅要重启终端，还得清掉 IDE 的 SDK 缓存、重载项目，甚至删掉 .gradle 目录下的 jvm-install.xml。M 系列上一旦混用架构，问题往往延迟暴露——编译通过，运行时报 UnsatisfiedLinkError 或直接 SIGSEGV。
