现代Java开发中绝大多数情况无需手动配置CLASSPATH；JDK 5后默认包含当前目录，Maven/Gradle等工具自动管理依赖，显式设置易引发冲突，仅遗留场景如老脚本、IDE运行配置或旧容器中可能遇到。
现代 Java 开发中，绝大多数情况下 不需要手动配置 CLASSPATH。JDK 5（Java 1.5）之后，java 和 javac 默认会把当前目录（.）加入类路径；Maven、Gradle 等构建工具也完全接管了依赖管理和类路径组装，显式设置 CLASSPATH 不但多余，还容易引发冲突。
什么时候仍可能看到 CLASSPATH 被修改？
仅在极少数遗留场景下才会主动操作：CLASSPATH 环境变量本身已基本被弃用，但你仍可能在以下情况遇到它：
- 运行老版本的 Java 应用（如 JDK 1.4 时代打包的
.jar启动脚本），脚本里用export CLASSPATH=...或set CLASSPATH=... - 在 IDE（如 Eclipse）的「Run Configuration」里手动填了
Classpath选项卡中的「User Entries」——这其实是 IDE 自己管理的，不等于系统级CLASSPATH - 某些嵌入式容器（如老版 WebLogic 启动脚本）会读取
CLASSPATH并拼接到启动命令中
手动设 CLASSPATH 的典型错误现象
一旦你全局设置了 CLASSPATH，就很可能破坏默认行为。常见症状包括：
-
Error: Could not find or load main class XXX：因为CLASSPATH覆盖了默认的.，导致当前目录下的.class文件找不到 - 同一个类加载了两个不同版本：比如你把
log4j-1.2.jar加进CLASSPATH，而项目又通过 Maven 引入了log4j-2.17.jar，JVM 可能按顺序加载到旧版，引发NoSuchMethodError -
javac编译成功但java运行失败：因为javac默认用CLASSPATH查找依赖类，而java命令没传-cp时只认默认路径，两者不一致
正确指定类路径的方式（替代 CLASSPATH）
需要用自定义类路径时，应优先使用命令行参数，而非环境变量：
立即学习“Java免费学习笔记（深入）”；
- 编译时加依赖：
javac -cp "lib/spring-core.jar:lib/commons-lang3.jar" Main.java
- 运行时指定：
java -cp ".:lib/*" Main
（注意：JDK 6+ 支持lib/*通配符，但不递归子目录） - IDE 中统一在项目设置里配「Module Dependencies」或「Libraries」，而不是改系统环境变量
- Maven 项目直接在
pom.xml里声明<dependency>，执行mvn compile或mvn exec:java时自动处理全部路径
真正需要警惕的不是“怎么配”，而是“为什么有人还在配”——多数 CLASSPATH 相关问题，根源是混淆了构建时依赖、运行时依赖和环境变量的作用域。越底层的配置，越容易被上层工具覆盖或绕过，留着反而成隐患。
