绝大多数情况下不该设为环境变量，因其会全局污染所有Java进程、引发版本冲突和类加载异常；推荐使用-cp参数、MANIFEST.MF的Class-Path或构建工具自动管理。
Java项目里classpath到底该不该设成环境变量
绝大多数情况下，不该。CLASSPATH设为全局环境变量会污染所有Java进程，导致不同项目jar包冲突、类加载顺序错乱，甚至出现NoClassDefFoundError却查不出原因。OpenJDK本身不依赖CLASSPATH环境变量启动，java和javac默认只认当前目录（.）——这恰恰是最安全的起点。
常见错误现象：
- 明明jar在lib目录下，运行时却报
ClassNotFoundException - 改了一个项目的依赖，另一个项目突然跑不起来
-
java -version正常，但java MyApp提示找不到主类
用-cp参数指定classpath才是标准做法
命令行显式传入-cp（或-classpath）是唯一可控、可复现、可调试的方式。它优先级高于环境变量，且只作用于当次执行。
使用场景示例：
- 编译含外部依赖的源码：
javac -cp "lib/slf4j-api-2.0.9.jar:lib/logback-classic-1.4.14.jar" src/Main.java - 运行带多个jar的程序：
java -cp ".:lib/*" com.example.Main（注意：通配符*只匹配jar，不递归子目录） - 混合class目录与jar：
java -cp "classes:config:lib/commons-lang3-3.14.0.jar" com.example.Launcher
关键细节：
- Windows用分号
;分隔路径，Linux/macOS用冒号: -
.代表当前目录，必须显式写上才能加载当前目录下的.class文件 -
lib/*在Java 6+支持，但lib/**/*.jar不被原生支持，需用构建工具处理
IDE或构建工具中classpath怎么管
IntelliJ IDEA、Eclipse这些IDE根本不读系统CLASSPATH环境变量。它们各自维护独立的模块级classpath，通过图形界面或.iml/.project文件管理。
实际项目几乎都用Maven或Gradle，此时classpath由pom.xml或build.gradle声明依赖，构建后生成的可执行jar自带MANIFEST.MF里的Class-Path字段——这才是生产环境该依赖的机制。
容易踩的坑：
- 在IDE里跑通了，命令行直接
java -jar app.jar失败 → 检查jar是否为“fat jar”，否则得用java -cp "app.jar:lib/*" com.example.Main - Maven打包没加
maven-shade-plugin，又忘了把依赖jar一起上传到服务器 → 运行时报错找不到第三方类 - 误在
~/.bashrc里export了CLASSPATH，导致CI流水线里mvn编译行为异常
什么情况下真要动CLASSPATH环境变量
极少数场景：比如你维护一个老旧Shell脚本，里面反复调用java命令且路径固定；或者你在OpenEuler服务器上部署一个不带构建脚本的遗留war包，需要让java -jar xxx.war能顺手加载$JAVA_HOME/lib/tools.jar里的工具类。
若真要设，只设这三样：
-
.（当前目录） -
$JAVA_HOME/lib/tools.jar（仅开发向工具类，如com.sun.tools.javac） -
$JAVA_HOME/lib/dt.jar（已废弃，JDK 9+移除，别加）
其他任何jar、路径、通配符都不应塞进环境变量。OpenJDK 11+默认不加载dt.jar，硬加反而引发UnsupportedClassVersionError。
真正麻烦的从来不是怎么设，而是设完之后忘记它还挂着——删掉CLASSPATH环境变量，比修一堆诡异的类加载问题快得多。
