Java开发的第一步并不是写代码，而是把运行和编译环境理顺。JDK提供了javac、java等核心命令，而IDE只是调用这些工具的外壳。如果底层配置混乱，再好的编辑器也会频繁报红。
一、JDK环境变量的底层原理
操作系统在执行javac或java命令时，会沿着PATH变量列出的目录依次查找可执行文件。JAVA_HOME本身不被系统命令直接读取，但大量构建脚本和IDE会依赖这个变量定位JDK根目录。很多人把JAVA_HOME设成了JRE路径，结果IDE找不到编译器，只能运行不能编译。
正确的做法是将JAVA_HOME指向包含bin、lib、include等目录的JDK主目录，例如C:Javajdk-17。随后在PATH中加入%JAVA_HOME%bin，这样切换版本时只需修改JAVA_HOME一处。在Linux或macOS中，可写在profile文件里：
# 设置JDK主目录 export JAVA_HOME=/opt/jdk-17 # 将编译器加入路径 export PATH=$JAVA_HOME/bin:$PATH # 验证配置 java -version javac -version
上面的脚本中，冒号用来分隔PATH中的多个路径。如果系统里装有多个JDK，用这种方式可以避免直接写死绝对路径带来的维护困难。修改后执行source命令让配置生效，再用两个-version命令确认输出一致。
二、IntelliJ IDEA中的SDK绑定
IDEA不会自动使用系统PATH里的JDK，它要求你在项目中显式指定Project SDK。打开项目结构面板，可以新增一个JDK并指向本地安装目录。这里选的版本决定了语法提示和字节码目标，如果选了JDK 8却写sealed class，编辑器会直接报错。
除了项目级SDK，还要检查模块的语言级别。语言级别必须不高于SDK版本，否则编译时会提示不支持的类文件版本。下面是一段在IDEA里通过代码读取运行环境的示例：
public class EnvCheck {
public static void main(String[] args) {
// 输出当前Java运行时版本
System.out.println(System.getProperty("java.version"));
// 输出编译器兼容级别对应的整数
System.out.println(System.getProperty("java.class.version"));
}
}
这段代码不需要任何第三方依赖，运行后能看到类似17.0.2和61.0的输出。若IDE里配置的SDK和实际运行的不符，排查这类打印值往往比看设置面板更直观。团队开发中建议把SDK配置写进文档，减少“在我机器上能跑”的问题。
三、Eclipse的配置差异与避坑
Eclipse使用自己的installed JREs列表，但它编译时需要的是JDK而非纯JRE。在偏好设置里添加JDK时，必须选到含有lib/tools.jar（旧版本）或完整模块的目录。Eclipse的编译器是内置的，不过仍依赖正确的执行环境来做语法校验。
一个常见误区是认为把JDK的bin放进PATH就万事大吉，Eclipse启动本身也绑定了一个JVM，若eclipse.ini里写的-vm指向了JRE，插件市场部分功能会异常。推荐在ini文件明确指定：
-vm C:/Java/jdk-17/bin/javaw.exe
这样Eclipse本身和项目使用同一JDK，避免版本错配。对于Maven项目，Eclipse会读取pom里的maven.compiler.source和target，这两个值要和IDE的JDK匹配，否则导出包后部署到服务器容易出现UnsupportedClassVersionError。
四、多版本共存的切换策略
实际工作中常需同时维护老系统和新技术栈。可以利用脚本快速切换JAVA_HOME，或者借助工具如jenv（macOS/Linux）管理。Windows下也可以写两个bat文件分别设置环境变量并注册到快速访问。
无论用什么方式，核心原则是：系统PATH只放一个当前默认JDK的bin，具体项目由IDE指向专用JDK。这样命令行和图形界面不会互相干扰。下表列出常见组合的问题表现：
| 现象 | 可能原因 | 解决办法 |
|---|---|---|
| IDE能运行不能编译 | JAVA_HOME指向JRE | 改为JDK根目录 |
| mvn打包报版本错误 | 编译器级别高于运行JDK | 降低source/target |
| 命令行找不到javac | PATH未含JDK bin | 追加%JAVA_HOME%bin |
配置本身不复杂，难在版本交叉时的条理。把环境变量、IDE设置、构建脚本三者对齐，Java开发环境才算真正稳定。