CLASSPATH 不必须配置，但不配易出 NoClassDefFoundError；JVM 默认加载当前目录，外部 JAR、多模块等场景需显式指定，且 -cp 优先级最高、覆盖 CLASSPATH 和默认 .。
CLASSPATH 不必须配置，但不配容易出 NoClassDefFoundError
Java 启动时默认会把当前目录（.）加入类路径，所以简单单文件编译运行不需要显式设 CLASSPATH。但一旦涉及外部 JAR、多模块项目或自定义包结构，缺省行为就会失效——比如你用 javac -cp lib/commons-lang3.jar Main.java 编译成功，却在运行时忘加 -cp，JVM 找不到 org.apache.commons.lang3.StringUtils，直接抛 NoClassDefFoundError。
常见踩坑点：
-
CLASSPATH环境变量一旦设置，会完全覆盖 JVM 默认的.，导致当前目录下 class 文件被忽略 - Windows 下用分号
;分隔路径，Linux/macOS 用冒号:，混用会导致整个路径失效 - IDE（如 IntelliJ）默认不读系统
CLASSPATH，它用自己的模块依赖机制，所以环境变量设了也“没用”
优先级：命令行 -cp > CLASSPATH 环境变量 > 默认 .
JVM 解析类路径有明确优先级顺序，不是叠加而是覆盖。这意味着：
- 即使你设置了
CLASSPATH=lib/a.jar，只要运行时加了java -cp lib/b.jar MyApp，那a.jar就完全不会参与加载 -
-cp和-classpath等价，但-cp更常用；注意它必须紧挨着java命令，写成java MyApp -cp lib/x.jar是无效的（JVM 把它当程序参数传给MyApp.main()） - 如果同时用
-cp和MANIFEST.MF中的Class-Path，后者只对该 JAR 内部引用生效，不扩展-cp的范围
现代构建工具（Maven/Gradle）让 CLASSPATH 变成“隐式管理”
你几乎不用手配 CLASSPATH，因为 mvn exec:java 或 gradle run 会自动把 compile 和 runtime 依赖拼成完整类路径传给 JVM。但要注意：
立即学习“Java免费学习笔记（深入）”；
- Maven 的
dependency:copy-dependencies默认不复制system范围依赖，这类 JAR 不进最终 classpath - Gradle 的
applicationDefaultJvmArgs不影响类路径，要改run.classpath或用shadowJar插件打胖包 - 用
java -jar app.jar时，JVM 只认MANIFEST.MF里的Class-Path，外部-cp被忽略——这是很多人打包后运行报错的根源
诊断类路径问题：用 -verbose:class 和 jdeps
当出现 ClassNotFoundException 或方法找不到时，别急着改配置，先看 JVM 实际加载了哪些类：
java -verbose:class -cp "lib/*:." MyApp 2>&1 | grep StringUtils
输出类似：[Loaded org.apache.commons.lang3.StringUtils from file:/path/to/lib/commons-lang3-3.12.0.jar]，能确认是否加载、从哪加载。
更进一步检查依赖传递性：
jdeps --class-path "lib/*" MyApp.class
它会列出 MyApp 直接依赖哪些包，以及那些包又依赖谁——比手动翻 pom.xml 更可靠，尤其面对 shaded/fat jar 时。
真正麻烦的从来不是“要不要配 CLASSPATH”，而是不同上下文（IDE、shell、CI、容器）下它的来源和作用范围完全不同，且错误信息从不告诉你“你少加了一个 JAR”，只冷冷甩一句“类没找到”。
