3月16日，Day1，我的Java环境搭建正式开始。说是环境搭建，其实不只是装一个JDK那么简单，而是要把JDK、开发工具、构建工具串起来，保证命令行能编译、IDE能运行、后续写代码不卡壳。这篇就把第一天做的每一步、遇到的一个小坑、以及最后用来确认环境可用的检查清单完整记录下来。如果你也是从零开始学Java，或者刚拿到一台新电脑准备把开发环境配好，可以直接照着文章里的顺序走一遍，应该能少走不少弯路。
1. 为什么Day1必须把环境一次性配到能用
1.1 先想清楚：JDK到底该选哪个版本
很多初学者上手Java的第一反应是下载最新版JDK，或者顺手装一个别人教程里用的旧版本。这两种做法我都不太推荐。先说结论：如果跟着某套教程学习，优先使用教程指定的JDK版本；如果教程没有特别说明，就用当前主流的长期支持版本（LTS）。LTS版本意味着官方会持续维护较长时间，社区资料、第三方库的兼容性也相对稳定，不会学了两个月才发现某个语法特性没人讨论。
JDK的大版本直接影响编译行为和运行环境。比如老项目里常见的javac -source 1.8这类参数，在新的JDK 17以上往往会出现"source option不再支持"的警告；反过来，用老版本JDK去跑新项目，又可能遇到Java编译器不认新版字节码的问题。所以我常跟身边人说，Day1选版本别太纠结，但要先定下来，别中途频繁切换，环境稳定比追求新版本重要得多。
如果你心里实在没底，可以这样判断：先把目标定在"能顺利编译运行代码"上，而不是"用上最新特性"。当前阶段的Java语法基础、面向对象、集合这些内容，在十年内的版本上都不会有本质差别，稳定的LTS版本足够你走完整个入门期。选完后，把它作为后续所有项目、所有工具的基准版本。
1.2 除了JDK，第一天还要准备什么工具
Java环境搭建的目标不是装一个JDK就宣告结束，而是要把整个开发链路理顺。我习惯把工具分成三块：JDK负责编译和运行，IDE负责写代码和调试，构建工具负责依赖管理、打包和自动编译。这三块在Day1必须全部打通，哪怕你暂时不理解什么是依赖管理，也建议先装上，因为后续学习几乎一定会用到。
以下是第一天建议准备的工具清单和各自的验证命令，我先给出来，后面每一块都会详细展开：
| 工具 | 作用 | Day1必须能跑通的命令或动作 |
|---|---|---|
| JDK | 编译和运行Java程序 | java -version、javac -version |
| IDE | 代码编辑、运行、调试 | 新建项目并运行Hello World |
| Maven | 依赖下载、项目构建 | mvn -v |
这三个工具从安装到联动，是Day1的完整主线。千万不能只装到"能打开某个安装包"就算完，必须验证到命令行和IDE都能正常跑程序，这样后续学习才能把精力放在语言本身，而不是反复折腾环境。
2. 分平台安装JDK：从下载到版本命令显示正确
2.1 Windows安装步骤与关键配置
Windows是大多数初学者接触的第一台电脑，安装JDK的步骤相对直观：下载对应系统位数的安装程序，双击后按向导安装。这里我特别建议把安装路径改到无空格、无中文的目录，比如D:\Java\jdk-17。很多Java工具在解析路径时会优先按空格切分，路径里带着"Program Files"这类名称，虽然大部分时候没问题，但一旦遇到深度嵌套的依赖，排查起来非常头疼。
安装完成后，第一次配置环境变量要注意顺序：
- 打开系统环境变量编辑面板，新建用户变量
JAVA_HOME，变量值填你实际安装的JDK路径。 - 在用户变量
Path中新增%JAVA_HOME%\bin，这样打开终端时系统才能找到java和javac命令。 - 重新打开一个终端窗口，分别执行
java -version和javac -version，确认显示版本一致。
:: Windows 验证命令 java -version javac -version如果你发现输入命令后提示"不是内部或外部命令"，不要急着怀疑配置有问题，先检查是不是终端窗口没重开。环境变量只在新的进程启动时才会重新读取，旧窗口里永远是旧变量环境。另外，我建议优先配置用户变量而不是系统变量，因为个人开发完全够用，还能避免以后卸载其他软件时误动系统级配置。
2.2 macOS和Linux的安装差异与常见习惯
macOS和Linux虽然命令相似，但安装习惯不太一样。macOS上的安装包分成图形安装包和解压包两种，图形安装包通常会自动配置好路径，解压包则需要手动移动目录并设置环境变量。Linux这边更自由，可以用包管理器直接安装，但包管理器自带的JDK版本不一定符合你的要求，有时候是系统默认的OpenJDK老版本。
我比较推荐手动解压的方式，把JDK安装到一个固定的、不带空格的目录，然后通过环境变量指向它。以macOS/Linux为例，编辑~/.bashrc或~/.zshrc文件，加入以下内容：
export JAVA_HOME=/opt/jdk-17 export PATH=$JAVA_HOME/bin:$PATH执行source ~/.bashrc或source ~/.zshrc让配置生效，然后运行java -version验证。如果你用的是图形终端，关掉重开一次更保险。macOS上还可以通过/usr/libexec/java_home -V查看所有已安装JDK的路径，这对管理多个版本很有用。
这两类系统的共同点在于：JAVA_HOME必须指向JDK的根目录，而不是bin目录。有些人手误写成/opt/jdk-17/bin，结果命令行能找到java，但其他依赖JAVA_HOME的工具反而找不到Java，这种低级错误最容易在Day1出现。
2.3 配置JAVA_HOME、PATH、CLASSPATH的合理边界
刚接触Java环境搭建时，我对这三个环境变量的理解也很模糊，后来才彻底想明白。JAVA_HOME是一个供其他程序识别的"入口"，Tomcat、Maven、IDE都会通过它来找JDK；PATH是在终端中输入java或javac时系统搜索命令的目录列表，两者协作才能让命令行正常使用。
至于CLASSPATH，除非你正在维护非常老的Java项目，否则我建议Day1直接不要手动设置，保持默认即可。现代JDK在启动时会自动把当前目录和标准类库加入类加载路径，手动配置CLASSPATH反而容易覆盖默认值，导致明明代码没问题却报ClassNotFoundException。我第一次配环境时就习惯性加了一个CLASSPATH=.，结果运行Hello World反而失败，去掉之后就恢复正常了。
这里还有一个原则：环境变量尽量少而清晰。能用系统默认的就别新增，每多一个环境变量，后续排查问题的范围就大一圈。Day1只需要配置JAVA_HOME和PATH，其他的等你真正需要时再说。
3. IDE与构建工具初装：从工具链角度做好联动
3.1 开发环境首次启动的项目配置思路
JDK装完后，下一步是安装IDE。选择哪一款不是重点，重点是首次新建项目时如何把IDE和刚才装的JDK正确关联起来。很多新手在IDE安装完后直接新建空项目，跑代码才报错，就是忽略了这个关联步骤。
以常见Java IDE为例，新建项目时通常会有一步选择JDK或SDK，这里必须选择你Day1安装的JDK版本。如果你电脑里存在多个JDK，IDE会列出所有可用版本，你需要显式指定某一个，而不是随便选"default"或"latest"。新建完项目后，还要检查Project Structure里的Language Level是否匹配。比如你选了JDK 17，Language Level也可以设为17，如果这里被默认设成了11或8，虽然代码能跑，但后续使用新语法会突然报错。
还有一个容易被忽略的配置是文件编码。Windows下IDE的默认编码可能是GBK，而绝大多数Java教程和开发者使用的是UTF-8。建议在IDE全局设置里把编码改成UTF-8，避免将来写中文注释或读取中文文本文件时出现一堆乱码。这个配置虽然不直接影响编译，但对学习体验影响很大，我Day1的时候就因为编码问题浪费了不少时间。
3.2 Maven安装、settings.xml调整和第一个工程验证
Maven是Java项目中最常见的构建工具，它能自动下载第三方依赖库、编译代码、打包发布。Day1可以不深入理解Maven的构建原理，但至少要把mvn命令跑通，否则后续教程里经常出现的mvn clean package会让你措手不及。
Maven安装包解压后，需要设置环境变量：
export MAVEN_HOME=/opt/apache-maven-3.9.x export PATH=$MAVEN_HOME/bin:$PATHWindows下同样在用户变量里新增M2_HOME或MAVEN_HOME，然后在Path中加入%MAVEN_HOME%\bin。配置完成后重新打开终端，执行mvn -v，你应该看到类似"Java version: 17"的输出。如果这里显示的Java版本和你配置的JDK不一致，先回头检查JAVA_HOME，因为Maven启动时完全依赖它。
Maven第一次使用时，建议打开settings.xml看几个关键配置：本地仓库路径和远程仓库镜像。默认本地仓库在当前用户目录的.m2/repository下，如果你C盘空间紧张，可以改到其他目录。远程仓库镜像则可以换成国内可访问的镜像地址，这样下载依赖的速度会明显提升。Day1不需要理解所有标签的含义，但知道这两个配置以后在哪里改，很关键。
4. 第一个Java程序：从命令行和IDE两个维度验证
4.1 用命令行手工编译运行，确认JDK本身没问题
环境变量配置完后，先别急着打开IDE，我习惯先在命令行里验证JDK是否真的可用。创建任意目录，新建一个文本文件，取名为Hello.java，写入最简单的代码：
public class Hello { public static void main(String[] args) { System.out.println("Hello, Java Day1!"); } }这里有一个Java基础规则：文件名必须与public类的类名完全一致，所以要命名为Hello.java，而不是hello.java或test.java。保存后，在这个目录打开命令行，执行：
javac Hello.java java Hellojavac命令执行后，如果目录里多了一个Hello.class文件，说明编译成功；java Hello运行时不要带.class后缀，因为java命令会按照类名在classpath中查找字节码文件，带了后缀反而报错。当控制台输出 "Hello, Java Day1!"，就证明JDK安装、环境变量配置、PATH指向全部正确。
这个步骤是我Day1最推荐的验证点，因为命令行是工具链的最底层，命令行跑通了，说明JDK本身没问题。之后万一IDE里出问题，排查范围就可以缩小到IDE配置，而不是怀疑JDK装坏了。
4.2 在IDE里跑通同样的代码，确认工具链衔接正常
命令行验证完成以后，打开IDE，新建一个项目。选择刚才配置好的JDK作为项目的SDK，然后创建包结构和类，把相同的代码粘贴进去，点击运行。如果IDE底部控制台打印出同样的问候语，说明IDE和JDK已经正确联动。
IDE跑通后，我建议再检查一下默认项目配置，因为很多IDE会区分"当前项目配置"和"默认项目配置"。如果你只改了当前项目的SDK，下次新建项目可能又会用另一个版本，这是很多"为什么新项目又报错"的根源。把默认项目结构里的SDK和Language Level也调整成统一版本，以后每次新建项目就不用重复设置了。
IDE和命令行属于两条并行的验证路径：命令行验证的是"底层工具是否正常"，IDE验证的是"上层工具是否把底层工具用对了"。两条路都通了，环境搭建这块才算真正落地。
5. Day1最常踩的坑：环境变量不生效、JDK版本错位和IDE识别失败
5.1 为什么配好了JAVA_HOME却仍提示找不到java
这个坑几乎每个初学者都会遇到。明明系统环境变量里已经写了JAVA_HOME，终端里却显示'java' 不是内部或外部命令。其实原因多半不是环境变量本身写错，而是你打开的终端窗口是在环境变量修改之前启动的。Windows上的资源管理器、终端窗口、甚至某些IDE拉起的子进程，都会缓存之前的环境变量快照，只有新启动的进程才能看到最新配置。
我的排查步骤通常是这样：先新开一个终端窗口，再执行java -version；如果还是不行，执行where java（Windows）或which java（Linux/macOS），看系统实际找到的Java到底在哪。有时候电脑里已经存在某个软件自带的JRE，并把它的路径提前排到了Path里，导致你手动配置的JDK根本排不上。这种情况下需要把%JAVA_HOME%\bin在Path中的位置前移，或者直接把多余的那个Java路径删除。
一个小经验：配置完环境变量后，如果是在Windows里，可以试试在地址栏输入cmd并回车，这样新开的终端通常能读到最新环境变量；如果还是不行，重启一下资源管理器或者重启电脑，省得反复猜测。
5.2 多个JDK共存时，如何让系统按预期使用指定版本
开发机里同时存在多个JDK是很常见的事：系统自带了某个版本，你自己又装了一个新版本，或者某个应用偷偷装了一个JRE。这会导致同一台机器上，某个终端窗口执行java -version显示的是一个版本，另一个窗口显示的是另一个版本，其实是因为不同窗口继承的PATH顺序或用户/系统变量生效顺序不同。
解决思路是统一切换到某个JDK时，做两件事：修改JAVA_HOME指向目标JDK根目录，同时确保Path中的%JAVA_HOME%\bin排在其他Java相关路径前面。在Windows上，用户变量会覆盖系统变量中的同名变量，但Path是拼接关系，所以只有把目标路径前置才有效。在Linux/macOS上，由于环境变量是显式赋值，后赋值的会覆盖先赋值的，通常不会有太多冲突。
需要特别注意的是IDE内部配置。即使系统层面的JAVA_HOME已经指向了正确版本，IDE项目里仍然会保存一个SDK路径，这个路径往往比系统环境变量拥有更高优先级。如果你在IDE里看到某个项目的Java版本不对，不要只改系统环境变量，还要进Project Structure里把项目SDK手动指过去。
5.3 IDE报"Invalid JDK"或"Source level"错误的排查链路
IDE报Invalid JDK，通常是因为配置的SDK路径变了，或者被识别为无效目录。比如你之前安装了JDK到某个路径，后来移动了文件夹位置，IDE里的配置仍然指向旧路径。解决方法是进入Project Structure，重新选择SDK目录，确保路径存在且是JDK根目录。
Source level错误则更隐蔽。这类问题常见形式是：代码明明用了JDK 17的语法，编译器却提示"source option 17不再支持"或"internal error"。这往往是因为Project Structure里的SDK选对了17，但Language Level或Java Compiler的Target bytecode version还停留在低版本，导致编译器用旧规则处理新语法。
我的排查链路是这样的：首先看Project Structure中Module的SDK是否为17，然后看Language Level是否也为17，再看Settings里的Java Compiler的Target bytecode version是否匹配，最后看项目里的构建配置文件有没有显式写死source和target。如果构建配置文件里写了source=1.8且target=1.8，就算IDE里选的是JDK 17，编译时依然会按1.8规则处理，这时要么升级构建配置，要么让编译级别和实际JDK保持一致。
这块原理有点像后厨点菜：你告诉服务员要一份新款菜品，但后厨记录还是旧菜单，出来的自然是旧菜。Day1遇到这类报错不用担心，按照SDK、Language Level、Compiler、构建配置的顺序逐层排查，基本都能查到问题点。
6. Day1结束前，建议做一次完整的环境体检
环境搭建是否真正完成，不是以"软件安装完成"为标准，而是以"所有环节都能协同工作"为标准。我习惯在第一天最后十分钟做一次完整体检，把以下内容一项项确认：
| 检查项 | 预期结果 |
|---|---|
java -version | 显示你选择的JDK版本 |
javac -version | 与上面一致 |
mvn -v | Java版本与JDK版本一致 |
| IDE新建并运行项目 | 控制台输出Hello World |
| 工作目录 | 代码文件的位置清晰，路径无空格无中文 |
如果表格里每一项都通过，说明Day1的Java环境搭建已经完成，可以安心进入语法学习。我在实际操作过程中还有一个习惯：把这套检查内容写成一份Markdown备注，保存到自己的工作目录里。下次换电脑、重装系统、或者帮别人配环境的时候，直接照着这份清单走，效率会高很多。
最后再分享一个小技巧：Day1不需要追求"最新版本"，也不需要追求把所有工具配置到完美。环境搭建最重要的是稳定和可复现，宁可多用主流LTS版本，也别天天更新JDK。当你把环境变量、IDE关联、Maven都跑通后，后面写Java代码就只是一个打开文件、运行程序的过程，不会再被环境问题打断。
