需先查清所有已安装JDK版本及路径：Windows查注册表HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\JDK，macOS执行ls /Library/Java/JavaVirtualMachines/，Linux用dpkg -l | grep jdk或rpm -qa | grep java；卸载后须手动清理残留文件、环境变量、IDE SDK配置及构建工具相关设置，并新开终端验证which java、java -version、mvn -v等结果是否符合预期。
确认当前系统中安装的JDK版本和路径
卸载前必须先搞清哪些JDK在运行、哪些只是残留。Windows 上执行 where java 和 java -version 只能告诉你当前 PATH 用的是哪个，但不会列出所有已安装 JDK。更可靠的方式是查注册表（Windows）或文件系统（macOS/Linux）：
- Windows：打开
regedit，导航到HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\JDK，这里会列出各版本的JavaHome路径 - macOS：JDK 通常装在
/Library/Java/JavaVirtualMachines/，直接ls /Library/Java/JavaVirtualMachines/就能看到所有包名（如jdk-17.0.1.jdk） - Linux（deb/rpm）：用
dpkg -l | grep jdk或rpm -qa | grep java；若手动解压安装，则需回忆或搜索jdk*目录
Windows下彻底卸载JDK（不止是控制面板）
通过「控制面板 → 程序和功能」卸载 JDK，只删掉了注册表项和部分程序文件，JAVA_HOME 环境变量、PATH 中的引用、以及 C:\Program Files\Java\ 下残留的目录往往还在。
- 手动删除对应 JDK 文件夹（如
C:\Program Files\Java\jdk-11.0.18） - 检查并清理环境变量：
JAVA_HOME是否指向已删路径？PATH是否还含%JAVA_HOME%\bin或绝对路径？ - 搜索整个系统是否有孤立的
tools.jar、rt.jar（JDK 8 及以前）或modules文件——这些常被 IDE 或旧构建脚本硬编码引用，删不干净会导致编译失败
macOS/Linux 手动清理 JDK 的关键路径
macOS 的 JDK 安装包（.dmg）卸载后不会自动清理，Linux 的 tar.gz 解压安装更是零卸载逻辑。重点不是“删文件”，而是确保没有进程或配置还在依赖它：
- macOS：删除
/Library/Java/JavaVirtualMachines/jdk-*.jdk后，运行/usr/libexec/java_home -V验证是否已从可用列表消失 - Linux：若用
tar -xzf解压到/opt/jdk-17，直接rm -rf /opt/jdk-17即可，但务必检查/etc/profile、~/.bashrc、~/.zshrc中是否还有export JAVA_HOME=... - IDE（IntelliJ/Eclipse）里配置的 SDK 不会随系统卸载自动清除，需进
Project Structure → SDKs手动删掉已失效条目，否则新建项目可能默认选错 JDK
验证卸载是否真正生效
很多人删完就以为完事了，结果跑 mvn compile 或启动 Spring Boot 时仍报 Unsupported class file major version ——说明构建工具或 IDE 还在用旧 JDK 编译。
立即学习“Java免费学习笔记（深入）”；
- 终端新开一个窗口（避免继承旧 shell 环境），执行：
which java、java -version、$JAVA_HOME/bin/java -version - 检查 Maven：
mvn -v输出的 Java 版本是否与预期一致；其实际使用 JDK 由MAVEN_OPTS或pom.xml中maven-compiler-plugin的source/target决定，和系统java命令未必一致 - Gradle 项目看
gradle.properties中的org.gradle.java.home，这个配置优先级高于系统环境变量
最易被忽略的是：某些 CI/CD 脚本、Dockerfile、或容器化环境里的 JDK 是独立打包的，本地卸载再干净也影响不了它们。清理前先确认你真正要解决的问题发生在哪一层——是开发机命令行？IDE 编辑器？还是 Jenkins 构建日志？
