classpath 环境变量在 jdk 21 中基本不必要；除非维护无构建工具的老脚本，否则设了反而易引发版本冲突、工具忽略、静默失效等隐性问题，推荐用 -cp 参数、manifest.mf 或构建工具管理类路径。
CLASSPATH 环境变量在 JDK 21 中基本不必要
直接说结论：除非你正在维护一个没有构建工具、纯靠 java 命令直跑 .class 文件的老脚本，否则 CLASSPATH 环境变量对 JDK 21 开发完全不是必需项，设了反而容易引发隐性问题。
为什么设了 CLASSPATH 反而可能出错
这个变量的“全局生效”特性在现代 Java 工具链里是个隐患：
-
CLASSPATH一旦设为系统级变量，所有java命令（包括 Maven、Gradle 启动的子进程）都会默认读取它——但绝大多数构建工具会主动忽略它，转而用自己组装的-cp参数，导致行为不可预测 - 常见错误现象：
NoClassDefFoundError或ClassNotFoundException在命令行复现，但在 IDEA 里能跑通，大概率就是环境变量CLASSPATH和项目实际依赖冲突 - 把
%JAVA_HOME%\lib\dt.jar或tools.jar加进CLASSPATH是典型错误：JDK 9+ 模块系统已废弃这些 jar 的显式引用，强行加入可能导致LinkageError或启动失败 - Windows 下用分号
;、Linux/macOS 下用冒号:分隔路径，若跨平台写脚本时混用，CLASSPATH会静默失效
JDK 21 默认类路径已经足够用
JDK 5 起就默认包含当前目录（.），JDK 21 完全延续这一行为。这意味着：
- 执行
javac Hello.java && java Hello不需要任何CLASSPATH配置就能成功 - 只要类文件在当前目录或按包结构组织（如
com/example/Hello.class），java com.example.Hello也能正常运行 - 模块路径（
--module-path）和类路径（-cp）机制更优先、更可控，JVM 启动时会按明确顺序解析，不依赖环境变量
真要手动控制类路径，应该怎么做
替代 CLASSPATH 环境变量的现代做法是显式传参：
- 单次运行：用
java -cp ".;lib/*" MyApp（Windows）或java -cp ".:lib/*" MyApp（Linux/macOS） - 打包分发：在 JAR 的
META-INF/MANIFEST.MF中写Class-Path: lib/gson.jar lib/logback.jar - 构建工具：Maven 的
mvn exec:java、Gradle 的gradle run会自动把target/classes和全部依赖拼成完整-cp字符串，无需人工干预 - IDE 运行配置：IntelliJ/Eclipse 的 Run Configuration → Classpath 页签里设置，和系统环境变量完全隔离
真正容易被忽略的是：哪怕你删掉了系统里的 CLASSPATH 变量，某些老脚本或 CI 中硬编码的 java -cp 依然会生效——所以排查类加载问题时，永远先看命令行参数，而不是环境变量。
