必须先运行uname -m确认Mac为arm64架构，否则后续安装x86_64版JDK会导致崩溃或性能骤降；推荐用/usr/libexec/java_home -arch arm64动态配置JAVA_HOME，并在IDE和Gradle中手动指定含arm64的绝对路径。
确认你的Mac确实是ARM64架构
别跳过这步——很多问题根源就在这。M1/M2/M3/M4芯片的Mac在终端运行 uname -m 必须输出 arm64，而不是 x86_64。如果看到后者，说明你当前终端正通过Rosetta运行，所有后续安装都可能错配。
常见错误现象：
- 下载了x86_64版JDK，装完
java -version显示版本但/usr/libexec/java_home -V列不出该JDK - IntelliJ里选不到刚装的JDK，或者选中后编译报
UnsatisfiedLinkError
正确做法是：关掉终端，右键“终端”→“显示简介”→取消勾选“使用Rosetta”，再重开终端验证。
用 /usr/libexec/java_home 动态获取JAVA_HOME
硬编码路径（比如写死 /Library/Java/JavaVirtualMachines/jdk-21.jdk/Contents/Home）在多JDK共存时极易出错，尤其当你升级或卸载某个版本后，$JAVA_HOME 会指向不存在的目录。
推荐写法（适用于 .zshrc）：
export JAVA_HOME=$(/usr/libexec/java_home -arch arm64) export PATH=$JAVA_HOME/bin:$PATH
关键点：
-
-arch arm64参数强制只匹配ARM64版本JDK，避免混入x86_64残留项 - 如果系统装了多个ARM64 JDK（如JDK 17和JDK 21），
/usr/libexec/java_home默认返回最新版；想固定某版本，加-v 17或-v 21 - 不要用
~符号缩写路径——VS Code的java.home设置、Gradle的JVM配置都不认
IDE和构建工具里的JDK路径必须绝对且原生
环境变量只影响终端启动的进程，IDE和构建工具往往绕过shell配置，自己找JDK。它们对路径格式和架构敏感度远高于命令行。
典型场景与对策：
-
IntelliJ IDEA：Preferences → Build, Execution, Deployment → Build Tools → Gradle → JVM → 点击右侧文件夹图标，手动选中
/Library/Java/JavaVirtualMachines/xxx.jdk/Contents/Home（路径里必须含arm64或aarch64字样） -
VS Code + Java Extension：设置里搜
java.home，填完整绝对路径，例如/opt/homebrew/opt/openjdk@21/libexec/openjdk.jdk/Contents/Home（Homebrew装的路径） -
Gradle Wrapper：检查项目根目录下
gradle.properties是否有org.gradle.java.home，值必须是ARM64 JDK的Contents/Home路径
容易踩的坑：IDE里点了“自动检测”或“Bundled JDK”，结果用的是自带的x86_64模拟版，跑单元测试时突然卡住或抛出 java.lang.UnsatisfiedLinkError: no xxx in java.library.path。
验证是否真走ARM64原生路径
光看 java -version 不够，它可能只是告诉你版本号，不反映底层执行架构。
更可靠的验证方式：
- 运行
/usr/libexec/java_home -V，输出每一行路径里必须含arm64或aarch64（比如jdk-21.0.3+7-aarch64） - 运行
java -XshowSettings:properties -version 2>&1 | grep "os.arch"，输出应为os.arch = aarch64 - 用
ps aux | grep java查看JVM进程，其可执行文件路径应指向ARM64 JDK目录，而非/Library/Java/JavaVirtualMachines/rosetta-jdk...这类虚构路径
最隐蔽的问题是：你装了ARM64 JDK，也配了环境变量，但某个脚本或CI配置里硬编码了旧路径，或者用了过时的 brew install openjdk（默认仍可能是x86_64），导致局部环境不一致。这种问题往往只在特定子模块编译时爆发，很难复现。
