企业官网建设流程全解析

上周帮一位同学远程看开发环境，画面切过去我差点笑出声：桌面上躺着三个不同版本的 JDK 安装包，安装目录里还各自装了一遍，结果 Android Studio 双击之后依然弹着那句几乎刻进每个安卓开发者记忆里的框——No JVM installation found. Please install a 64-bit JDK. If you already have a JDK installed, define a JAVA_HOME variable in Computer > System Properties > System Settings > Environment Variables.这行字的迷惑之处在于，它同时抛出了两个问题：要么你没装 JDK，要么你装了但环境变量没配对。而实际情况往往是第三种——JDK 装了、环境变量也配了，问题出在 Android Studio 根本没去那些地方找。这篇就把这个报错从根上拆开：JVM 到底是什么、为什么 Android Studio 启动第一步就要它、JDK 该选哪个版本、环境变量有哪几种写法、以及装完之后 Studio 与 Gradle 各自的 JDK 怎么分别指定。全文按“先定性、再选型、再安装、再指定、最后排查”的顺序推，代码和配置都能直接抄，适合刚上手 Android 开发的新人，也适合被多版本 JDK 搞晕的老手对照复查。

1. 先把问题定性：这个报错到底在说什么

1.1 报错原文与两种完全不同的触发场景

那句提示的完整语义是“没有找到可用的 JVM 安装”。注意它说的是 JVM，不是 JDK，也不是 Java。JVM 是运行时虚拟机，是真正把.class字节码翻译成机器指令的执行体；JDK 是包含 JVM 的开发套件。Android Studio 本身是一个用 Java/Kotlin 写的桌面应用，它的安装包里其实塞了一整套运行时，正常情况下用户根本不该看到这个弹窗。

所以只有在两类场景下它才会冒出来。第一类是运行时缺失：安装目录下那个负责提供虚拟机的子目录被删了、被杀毒软件误杀隔离了、或者你下的是被人动过手脚的绿色精简包，运行时压根没打进去。第二类是运行时能跑但版本不认：某些旧版启动器会跳过自带运行时去系统里找，找到的版本又低于它的最低要求，于是继续往下找，找完全部候选还是空，最后报同一句话。

这两类问题的解法完全不一样。第一类是补文件或者重装，堆环境变量没有意义；第二类是改指向或者升级 JDK。很多人一看到提示就疯狂配环境变量，方向从一开始就偏了。判断方法很简单：打开 Android Studio 的安装目录，看有没有jbr这个文件夹，比如 Windows 下通常在C:\Program Files\Android\Android Studio\jbr，里面是不是有bin\java.exe。有，就是第二类；没有，就是第一类。

1.2 Android Studio 的启动链路里 JVM 站在哪一环

把启动流程拆成四步就清楚了。第一步，你双击的那个studio64.exe（macOS 下是包内的可执行文件，Linux 下是studio.sh）其实是个极小的原生启动器，它自己不是 Java 程序，只负责准备工作。第二步，启动器按照一套固定的优先顺序去搜索一个可用的 JVM，这一段是全文的核心，后面单独展开。第三步，找到 JVM 之后启动器会读取同目录下的 vmoptions 配置文件，把堆内存、编码、GC 参数这些一次性塞进去。第四步，真正的 IDE 主进程在这个 JVM 上跑起来，后面打开项目、加载插件、启动 Gradle 守护进程，全都是第四步之后的事。

这四步里，报错只可能出现在第二步。第三步之后出问题，报的就不是“找不到 JVM”，而是 OOM、卡死、插件崩溃。我特意把这条链路写出来，是想强调一个容易混淆的点：报错发生在 JVM 被定位之前，所以任何在 IDE 内部做的设置都不可能影响它。有些人把 Studio 装好了、能打开了，后来手贱在设置里把 Gradle 的 JDK 改错了，导致构建失败，那是另一码事，跟启动报错没有关系。两件事分开看，排查效率能差一倍。

1.3 为什么“我明明装了 Java”依然找不到

这是最高频的认知偏差。装了 Java 不等于系统里有个能被启动器自动发现的 JDK。启动器找的是三样东西：一个是明确的路径指向，一个是注册表或系统目录里的登记项，一个是标准位置下的默认安装。你手动解压了一个压缩包版 JDK 到 D 盘某个自建目录，这三样一样都不沾，启动器当然找不到。

还有一个更隐蔽的原因：装的是 JRE 而不是 JDK。JRE 是运行时环境，它确实有 JVM，但结构上跟 JDK 不同，缺javac、缺include、缺开发工具链。部分老版本的启动器在探测时会做结构校验，看到没有编译器就判定这不是一个合格的开发环境，直接跳过。所以别拿 JRE 去糊弄，省那点安装空间最后会还回来。

另外还有一种情况值得单独提一句：系统里存在多个 Java，.exe的垃圾残留、旧版 Oracle 客户端带进来的运行时、某些办公软件捆绑的运行时，它们在Path里排在前面。你在命令行敲java -version看到的是 A 版本，启动器读JAVA_HOME读到的是 B 路径，两个信息打架的时候人就会开始怀疑人生。统一事实来源是排查这类问题的第一原则，后面第 3.4 节会讲怎么用三条命令确认到底哪个在生效。

2. JDK 选型：版本不对，装了也白装

2.1 版本对应关系：一张表说清 Studio、Gradle、AGP、JDK

选版本这件事，比“装最新版”要讲究。Android 构建链上有四个角色需要版本协同：Android Studio 本体、Gradle 构建工具、AGP 也就是 Android Gradle 插件、以及 JDK。四者之间存在硬性的最低版本约束，装低了跑不动，装高了也可能因为 Gradle 不认而报Unsupported class file major version。

表的用法是从下往上倒推。你先确定手头项目要用哪个 AGP，然后查 AGP 要求的最低 JDK，再看 Gradle 版本能不能跑在这个 JDK 上，最后确认 Studio 版本跟不跟得上。绝大多数人的实际困境是：项目是老项目，AGP 还是 7.x，JDK 装了 21，编译时满屏红字。这种时候不要怀疑代码，直接降 JDK。

实践中最省事的组合是 JDK 17。它对 AGP 7.4 到 8.x 全线兼容，是这几年最稳的“万能版本”。新项目用 AGP 8.x 完全够，老项目稍作调整也能跑。除非你明确要用到 21 的新特性，否则没必要追新。JDK 21 在部分旧版 Gradle 上会有Unsupported class file major version 65的报错，这个错误的本质是 Gradle 里内置的字节码解析器不认识 65 这个版本号，光看报错文字根本猜不到是 JDK 太新。

2.2 发行版怎么挑：别在下载页上发呆

OpenJDK 是规范，市面上提供实现的有好几家，都免费也都合规。选择标准其实就三条：长期支持版本、更新维护活跃、安装器行为规范。

我自己的取舍逻辑是：优先选那种带标准安装器、会把安装路径登记到系统标准位置的发行版。原因很实在——启动器能自动发现，你连环境变量都不用配。压缩包版本虽然干净、可移植，但每次换机器都要手动配一遍，长期看是负担。带安装器的版本装完基本就在标准位置了，JAVA_HOME指过去就能用。

另一个容易忽略的点是安装器的“附加选项”。有些安装器会问要不要设置JAVA_HOME、要不要把 java 加进Path、要不要注册为系统默认。这三个选项全勾上，能省掉后面一大堆手写配置。唯一要注意的是，如果机器上已经有别的 JDK，安装器可能会提示是否覆盖默认，这时候想清楚你要哪个当默认，别一路下一步。

2.3 JDK 与 JRE 的区别，为什么只装运行时不顶用

用一个类比：JDK 是厨房，JRE 是餐厅。餐厅能吃饭，但做不了菜。你用 Java 写代码、编译、打包，这些“做菜”的动作全在 JDK 里。JRE 只提供虚拟机加核心类库，能把已经做好的.class端上来，但不给你锅。

具体到目录结构，两者差别一眼可见。JDK 根目录下有bin（含javac.exe、jar.exe、jlink.exe）、jmods、include、lib；JRE 只有bin（仅java.exe等运行时）和lib。Android Studio 的启动器在探测时如果只看到java看不到javac，某些版本会判定环境不完整。Gradle 在构建时更是必须要javac，不然编译任务直接失败。

所以安装时的第一步自查：确认下载页面上写的是 JDK 而不是 JRE，确认安装完成后bin目录里能找到javac。这两条过了，就排除了最常见的一种“装了但没用”的情况。

2.4 安装路径的三条红线

路径问题在 Windows 上尤其致命，我把它单独拉出来说，因为它的症状非常迷惑——环境变量明明配对了，java -version也能出结果，Studio 就是报找不到。

第一条红线，路径里不要有空格。C:\Program Files\Java\jdk-17这种路径，在环境变量里不整体加引号的话，被某些解析器按空格切开，后半截就成了独立参数。更稳的做法是装到C:\Java\jdk17这类短路径下。

第二条红线，路径里不要有中文和特殊符号。这不只是 Studio 的问题，Gradle、NDK、CMake 一整条链路上都有大量工具对非 ASCII 路径处理不干净。路径里带个中文目录名，报错信息往往长得莫名其妙，比如“找不到文件”，实际上文件就在那儿。

第三条红线，不要装在需要管理员权限才能读的深层目录。有些公司电脑把用户目录重定向到网络盘，JDK 装在网络路径上，读权限时有时无。启动器探测超时之后就当作没找到，报的还是一句“no JVM”。

这三条的验证成本极低，装之前花十秒看一眼路径，比装完排查两小时划算。

3. 落地安装：三个平台的环境变量怎么配

3.1 Windows：JAVA_HOME 与 Path 的正确写法

Windows 上的核心是两个变量。JAVA_HOME指向 JDK 的根目录，不带bin，不带结尾反斜杠。比如C:\Java\jdk17，写成C:\Java\jdk17\bin是错的，写成C:\Java\jdk17\也是给自己找麻烦。这个变量被大量工具链依赖，Gradle、Maven、Tomcat、Android Studio 的启动器都会读它。

Path里要加的是%JAVA_HOME%\bin，注意是引用变量而不是硬写路径。好处是以后换 JDK 只改JAVA_HOME一处，Path不用动。这条要尽量排在Path列表靠前的位置，因为Path是从上往下顺序查找的，系统目录C:\Windows\System32里也可能存在java.exe（旧版 Oracle 安装会往那儿丢文件），排在前面就会抢先。

配置位置有两种：用户变量和系统变量。用户变量只对当前账户生效，系统变量对本机所有用户生效。个人开发机配用户变量就够，配系统变量需要管理员权限但影响面更大。两者不要同时配成不同的值，那是给自己埋雷——某些进程读用户变量，某些读系统变量，出现“命令行能跑、IDE 不能跑”的诡异现象。

改完变量必须重开终端。已经开着的 cmd 或 PowerShell 里的环境变量是启动那一刻的快照，不会自动刷新，这是新手最常见的“配了但没用”的原因。

3.2 macOS：从/usr/libexec/java_home说起

macOS 的 Java 管理方式跟 Windows 完全不同。系统不依赖JAVA_HOME去找 Java，而是维护一个固定的目录/Library/Java/JavaVirtualMachines/，每个 JDK 是一个.jdk结尾的包，装进去就自动被识别。系统自带一个工具/usr/libexec/java_home，它负责告诉你当前默认的 JDK 在哪。

验证命令是/usr/libexec/java_home -V，注意是大写 V，它会列出机器上所有已注册的 JDK 及版本。加版本参数可以指定，比如/usr/libexec/java_home -v 17拿到 17 的路径。这套机制的好处是多版本共存非常干净，切换只需要改环境变量里的版本参数。

JAVA_HOME在 macOS 上不是必须的，但 Android Studio 的启动脚本和 Gradle 都会读它。推荐在 shell 配置文件（新系统默认是 zsh，配置文件是~/.zshrc）里加一行：

export JAVA_HOME=$(/usr/libexec/java_home -v 17) export PATH=$JAVA_HOME/bin:$PATH

这种写法比硬写路径优雅，以后装了新版本只要改-v 17这个参数。注意PATH的拼接顺序，$JAVA_HOME/bin要写在$PATH前面才会优先。

有一个 macOS 特有的坑：安装器装完之后可能不会立刻注册到java_home的列表里，需要重开终端或者执行一次/usr/libexec/java_home -V触发。还有人装的是压缩包版，解压到了~/Downloads，这个目录根本不在系统扫描范围内，java_home永远看不见它。压缩包版必须手动放到/Library/Java/JavaVirtualMachines/下面才有效，而且目录结构要对，得是xxx.jdk/Contents/Home这种形态。

3.3 Linux：update-alternatives 与 profile.d

Linux 发行版大多用update-alternatives这套机制管理多版本。装完 JDK 之后执行注册，形如：

sudo update-alternatives --install /usr/bin/java java /opt/jdk17/bin/java 100 sudo update-alternatives --install /usr/bin/javac javac /opt/jdk17/bin/javac 100

末尾那个数字是优先级，数字大的胜出。切版本用--config：

sudo update-alternatives --config java

它会列出所有注册过的候选让你选序号。这套机制的好处是全系统统一，java、javac、jar全部走同一套链接，不会出现java是 17 而javac是 11 这种错配——这种错配在开发机上是真实会发生的，症状是编译能过但运行时版本不符。

JAVA_HOME在 Linux 上同样需要显式配。Debian 系可以把配置写到/etc/profile.d/java.sh：

export JAVA_HOME=/opt/jdk17 export PATH=$JAVA_HOME/bin:$PATH

放profile.d的好处是对所有用户生效，且登录时自动加载。如果只给自己用，写到~/.bashrc或~/.zshrc就行。注意profile.d里的脚本要有可执行权限，并且文件名以.sh结尾才会被加载。

还有一个细节：某些发行版的包管理器装的 JDK 会自动配好JAVA_HOME，但配的位置可能指向一个不符合预期的版本。装完先用echo $JAVA_HOME看一眼，别假设它是空的。

3.4 三条命令验证，别急着开 Studio

配完之后先别开 IDE，在终端里跑三条命令，全部通过再往下走。第一条：

java -version

输出里会显示版本号和发行商。看清版本号是不是你期望的那个。第二条：

javac -version

很多人只验证第一条，结果javac根本不在Path里，或者指向另一个版本。第三条：

echo $JAVA_HOME

Windows 下是echo %JAVA_HOME%。这条输出必须是一个真实存在的目录，而且里面的bin要有javac。

三条命令对应的检查项分别是：运行时可用、编译器可用、变量指向正确。三个条件缺一个，都会在后面某个环节以完全不同的报错形式爆发出来。我见过最坑的一种情况是java -version正常、javac -version报“不是内部或外部命令”，原因是Path里只加了%JAVA_HOME%\bin之外的东西，漏了它。这种状态下 Studio 能打开，但一构建就报找不到编译器，报错信息跟 JDK 八竿子打不着，能排查一下午。

4. 让 Android Studio 真正认到 JDK

4.1 查找顺序：STUDIO_JDK 优先于 JAVA_HOME

这一节是全篇最关键的部分，也是绝大多数教程漏掉的部分。启动器搜索 JVM 有一套明确的优先级，从上到下依次是：

第一个是STUDIO_JDK环境变量。这个变量专门给 Android Studio 用，优先级最高，指向一个 JDK 根目录。设了它，启动器就直接用，后面的一概不看。这是精准控制的最优解——不影响系统里其他程序，只让 Studio 用你指定的那个。

第二个是JDK_HOME。这是个通用的、优先级比JAVA_HOME高一点的变量，语义上表示“这台机器上我最想用的 JDK”。

第三个是JAVA_HOME。这个大家最熟，也是各种工具默认读的。

第四个是系统默认位置。Windows 下会去查注册表里的 Java 登记项，macOS 下走java_home那套，Linux 下看/usr/bin/java这个软链。老版本还额外扫描一些历史遗留路径。

这张优先级表的价值在于：当系统里存在多个 JDK，你可以用STUDIO_JDK单独给 Studio 指定一个，而完全不动JAVA_HOME。比如你命令行里想用 JDK 11 跑一些老脚本，但项目要用 JDK 17，JAVA_HOME设成 11，STUDIO_JDK设成 17，两边互不干扰。这比反复切环境变量省太多事。

需要注意的是变量名拼写，是STUDIO_JDK，中间没有下划线，不是STUDIO_JVM也不是ANDROID_STUDIO_JDK。这几个错拼我都见过，写错了当然无效。

4.2 一个常见误区：vmoptions 文件里写路径

网上能搜到一种说法：在studio64.exe.vmoptions里加一行指向 JDK 的路径就能解决报错。这个说法是错的，而且错得很隐蔽，因为你加完之后文件确实“生效”了，但报错依旧。

原因回到第 1.2 节的链路：vmoptions 是第三步读的，此时 JVM 已经找到了。文件里的内容是喂给 JVM 的参数，比如-Xmx2048m、-Dfile.encoding=UTF-8、-XX:+UseG1GC这些，全是 JVM 自己的开关，没有任何一行是用来指定“JDK 在哪个目录”的。写路径进去，JVM 会把它当成一个不认识的自定义属性，默默忽略，然后你继续面对同一个弹窗。

这个文件真正有用的场景是调内存。默认堆值在开发大型项目时会不够，表现是频繁 Full GC、界面卡顿、索引一直转圈。这时候在 vmoptions 里调-Xmx才是对症。经验值是这样算：看机器物理内存，16G 的机器给 IDE 分配 2048 到 3072 兆比较合适，32G 的机器可以给到 4096，同时 Gradle 通过gradle.properties里的org.gradle.jvmargs单独分配一份，两边加起来别超过物理内存的一半，剩下的要留给编译进程、模拟器和系统本身。

还要注意 vmoptions 有两个位置：IDE 安装目录下的全局版本，和用户配置目录下的个人版本。后者优先级更高，改错地方会一直不生效。用户配置目录在 Windows 下是%APPDATA%下的对应产品目录，macOS 下是~/Library/Application Support下的对应目录。改之前确认自己改的是哪一个。

4.3 安装目录下的 jbr 才是它真正的“亲儿子”

回到最根本的一条：正规渠道装出来的 Android Studio，安装目录里自带一个jbr文件夹，全称是 JetBrains Runtime，是专门为这类 IDE 优化过的运行时，包含了一些界面渲染相关的补丁。启动器优先使用这个内置运行时，只有在它不存在或者不可用时，才走 4.1 节那套外部查找流程。

这意味着两件事。第一，绝大多数正常安装的机器根本不该出现“找不到 JVM”，出现了就说明jbr有问题。第二，修这个问题最快的办法往往不是配环境变量，而是让jbr恢复。

jbr出问题的典型原因有三个。一是安装过程被中断，文件没拷全；二是杀毒软件把jbr\bin下的某个 dll 当可疑文件隔离了；三是某些“精简版”“绿色版”安装包为了压体积，把jbr整个删掉了。第一、二种重装或者从隔离区恢复即可，第三种最麻烦，只能换正规安装包。

判断方法很直接：打开安装目录，进jbr\bin，看java.exe在不在，双击它（Windows 下会闪一下窗口）或者命令行执行jbr\bin\java.exe -version，能出版本信息就说明运行时完整。这个动作三十秒能做完，比翻环境变量快。我在帮人看环境时，第一步永远是看这个目录，能省掉一大半无效排查。

如果确实需要让 Studio 用外部 JDK 而不是内置的，就把STUDIO_JDK指过去。不要靠删jbr来强制它用外部的，那是给自己制造故障——万一外部 JDK 也有问题，你就同时失去了两个选项。

4.4 装好之后还得改 Gradle JDK

这里有个概念必须掰清楚：启动 Android Studio 用的 JVM，和编译你的 Android 项目用的 JVM，是两个独立配置。前者解决的是 IDE 能不能打开，后者解决的是项目能不能构建成功。很多人卡在第一步解决了，第二步依然报错，原因就是只改了一个。

Gradle JDK 的设置在 IDE 里：打开设置，找到构建工具分类下的 Gradle 项，里面有一个“Gradle JDK”的下拉。这个下拉的选项包括内置运行时、检测到的 JDK、以及手动指定的本地目录。选哪个取决于项目用的 AGP 版本，参照第 2.1 节的表。

还有一个更彻底的做法，写在项目根目录的gradle.properties里：

org.gradle.java.home=C:/Java/jdk17 org.gradle.jvmargs=-Xmx2048m -Dfile.encoding=UTF-8

第一行是给这个项目的构建进程指定 JDK，优先级高于 IDE 里的设置。好处是配置跟着项目走，换机器、换同事、上持续集成环境，行为都一致。坏处是路径写死了，别人电脑上没有这个路径会直接构建失败。所以我倾向的做法是：个人机器上不动这一行，靠 IDE 设置；团队项目里写进文档而不是写进代码。

org.gradle.jvmargs那一行倒是建议所有人都加上。它控制的是构建进程的堆大小和编码。不加的话，大项目在多模块构建时容易 OOM，报的是Java heap space，看着像代码问题其实是内存问题。-Dfile.encoding=UTF-8则能避免一批中文乱码，尤其是注释里有中文、日志里有中文的场景。

5. 踩坑实录与速查表

5.1 常见问题速查

这张表按“从启动到构建”的顺序排的，遇到问题先定位自己卡在哪一环，再往下查对应的行，比漫无目的试错快得多。

5.2 三个真实场景复盘

第一个场景是前阵子遇到的：一位同学的机器上同时存在三个 JDK，命令行里java -version显示 11，javac -version显示 17，IDE 里的 Gradle JDK 显示 21。三个数字全不一样。这种状态之所以能形成，是因为三处读取的是三个不同的来源：java走Path里第一个命中的，javac走另一个目录，IDE 走自己的设置。修复动作是先把Path里所有 Java 相关项清干净，只留一条%JAVA_HOME%\bin，再把JAVA_HOME统一成 17，最后在 IDE 里把 Gradle JDK 也设成 17。三处对齐之后，之前那些莫名其妙的编译错误全消失了。这件事的教训是：环境里永远只留一个“事实来源”，其余全部清掉或显式隔离。

第二个场景是一位同事把 JDK 装在了一个带中文名的目录下，路径长这样：D:\开发工具\jdk-17。命令行的java -version完全正常，但 Studio 一构建就报找不到某个 jar。查了很久才发现是 Gradle 在处理这个路径时编码转换出了问题，生成的命令行参数被截断。换到D:\dev\jdk17之后一切正常。这类问题最难查，因为报错信息跟真实原因毫无关联。后来的做法是：所有开发工具链的安装路径，一律只用英文字母、数字、短横线，长度尽量短。

第三个场景是关于安装包来源的。有人从某个网盘下了个“免安装精简版”Studio，解压即用，体积小了一半。打开就报找不到 JVM。看安装目录，jbr文件夹确实存在，但里面只有十几个文件，bin目录是空的。这种包就是把运行时抽掉了换体积，任何环境变量配置都救不回来，因为根本没有可用的运行时。最后是重新下了正规安装包解决的。这件事我后来经常拿出来说：开发工具这东西，省下来的下载时间最后都会变成排查时间，不划算。

5.3 多 JDK 共存的隔离策略

做安卓开发时间长了，机器上大概率会有两三个 JDK：一个跑老项目，一个跑新项目，可能还有一个是别的语言工具链带进来的。共存的关键不是“只留一个”，而是“让每个使用方明确知道该用哪个”。

我的做法分三层。第一层，JAVA_HOME指向那个“默认的、最常用的”版本，通常是 17，命令行日常操作都走它。第二层，STUDIO_JDK指向 IDE 想用的版本，如果需要跟JAVA_HOME不同就在这里单独指。第三层，每个项目在自己的配置文件里声明构建用的 JDK，通过版本管理工具（比如 Gradle 的 toolchain 特性）自动匹配，避免手工切。

Gradle 的 toolchain 是个好东西，写法大致是：

java { toolchain { languageVersion.set(JavaLanguageVersion.of(17)) } }

它的作用是告诉构建系统“这个项目需要 Java 17”，如果本机没有，Gradle 会尝试自动下载一个匹配的。这样项目就不依赖开发者机器上装了哪个版本，可移植性大幅提升。团队协作场景下这一招能省掉大量“在我机器上是好的”的扯皮。

当然 toolchain 也有代价，它会往本地缓存里下载新的 JDK，占空间，且首次构建会慢。内网环境还可能下载失败。所以它适合团队项目，个人小项目用不着，直接指定路径就行。

6. 几个我反复验证过的操作习惯

装了这么多年环境，我总结出几条几乎每次都能派上用场的习惯。第一条是先看安装目录再看环境变量。报“找不到 JVM”的时候，第一动作永远是打开安装目录看jbr\bin\java.exe在不在。在，说明是版本或指向问题；不在，说明是文件缺失。这一个动作能把排查范围砍掉一半，比翻十篇教程有用。

第二条是改完环境变量必须重开终端。这条听起来像废话，但我见过太多人在已经开着的窗口里改完变量，然后echo出来还是旧值，接着开始怀疑人生。Windows 上更彻底的做法是注销重登，因为有些进程持有环境块的副本，新开的子进程继承的还是旧的。

第三条是给每个 JDK 起个能认出来的目录名。不要用默认的jdk-17.0.9这种，装了三四个之后根本分不清谁是谁。我自己的命名是jdk17-tem、jdk11-oracle这种，带版本带来源，一眼就能看出该删哪个。目录名短一点还有个附带好处，就是前面说的路径长度问题。

第四条是升级 Studio 之前先记下当前的 JDK 版本。大版本升级有时候会把内置运行时从 17 换到 21，而你的项目还停在 AGP 7.x，升完之后一打开就报错，回头去找“升级前是什么版本”已经想不起来了。花十秒截个图或者记一行字，能省掉半小时的回忆。

最后说一个容易被忽略的检查点：如果你的机器上装了不止一个 IDE 产品（比如还有别的 JetBrains 系工具），它们共享同一套STUDIO_JDK之外的查找逻辑，但不共享 vmoptions。改配置的时候确认改的是目标产品对应的文件，别改了半天改到隔壁去了。这类低级错误我自己犯过不止一次，每次都是查了半小时才发现文件改错了地方。