CLASSPATH 是 JVM 运行时定位 .class 文件和 JAR 包中类的路径集合，仅影响 java、javaw、jar 等命令，不参与编译；默认为当前目录，现代 IDE 和构建工具基本忽略环境变量 CLASSPATH。
CLASSPATH 是什么，它到底管谁？
CLASSPATH 是 JVM 启动时用来定位 .class 文件（以及 JAR 包里的类）的一组路径。它不决定源码怎么编译，只影响运行时——也就是 java 命令执行时，JVM 上哪去找你写的类、依赖的第三方类。
- 它只对
java、javaw、jar等命令生效，javac编译时默认不读CLASSPATH（除非显式加-cp） - 如果没设
CLASSPATH，JVM 默认用当前目录（.）作为类路径 - 它不是“让 Java 找到 JDK”的变量——那是
JAVA_HOME和系统PATH的事
IDE 和构建工具（Maven/Gradle）还看 CLASSPATH 吗？
几乎不看。现代开发中，CLASSPATH 环境变量本身基本被绕过了：
IntelliJ/Eclipse 运行配置里填的是「Module classpath」或「Run Configuration → Classpath」，和系统环境变量无关
-
mvn exec:java或gradle run会动态生成临时 classpath，并通过-cp参数传给 JVM，完全无视你设的环境变量立即学习“Java免费学习笔记（深入）”；
Spring Boot 的
java -jar app.jar更是把所有依赖打进 fat jar，启动时只认 jar 内部的META-INF/MANIFEST.MF中的Class-Path字段如果你在 IDE 里改了系统
CLASSPATH，大概率不会生效，还可能干扰构建脚本的预期行为某些老脚本或 CI 中手动写
java -cp ... MyApp，这时环境变量反而会被忽略——因为-cp优先级高于环境变量
什么时候你真得碰 CLASSPATH？
只有两类场景绕不开手动设它：
在没有构建工具的极简环境里直接运行 class 文件：比如
javac Hello.java && java Hello成功了，但换成java com.example.Hello就报ClassNotFoundException，这时就得确认包路径是否在CLASSPATH里，或者改用java -cp . com.example.Hello调试遗留 Shell/Batch 脚本时发现它依赖全局
CLASSPATH加载插件 JAR（比如某些老版本 Ant、WebLogic 启动脚本）Linux/macOS 下设法：
export CLASSPATH="/path/to/lib/a.jar:/path/to/classes"（注意用:分隔）Windows 下：
set CLASSPATH=C:\libs\b.jar;C:\classes（注意用;分隔）永远别把 JDK 的
rt.jar或tools.jar手动塞进CLASSPATH——JVM 自己管核心类，加了反而可能引发LinkageError
为什么设了 CLASSPATH 还报 NoClassDefFoundError？
这个错误常被误认为是 CLASSPATH 没配对，其实更可能是以下原因：
- 类确实存在，但它的某个静态初始化块抛了异常（比如数据库连接失败），导致类加载失败；后续再引用就报
NoClassDefFoundError，而不是ClassNotFoundException - 路径里混用了相对路径，而当前工作目录（
pwd）和你预想的不一致——建议一律用绝对路径测试 - JAR 包本身损坏，或里面缺少
META-INF/MANIFEST.MF（某些打包方式会漏掉） - 同一个类被多个 classloader 加载（比如 Web 容器里应用 classloader 和 shared classloader 冲突），这时看日志比调
CLASSPATH有用得多
真正需要盯住 CLASSPATH 的时刻，往往出现在脱离工具链的裸 JVM 场景里——比如容器里跑一个没打包的 Java 工具类，或者排查某个 shell 脚本为何在一台机器上能跑、另一台不行。这时候，echo $CLASSPATH 或 echo %CLASSPATH% 看一眼，再对比 java -verbose:class -cp ... MyApp 的输出，比猜强得多。
