java从jdk 5起默认使用当前目录（.）作为classpath，无需手动配置；其作用是告诉jvm按顺序查找.class和.jar文件，缺失则抛noclassdeffounderror等异常。
Java 从 JDK 5（即 Java 5）开始，默认不再需要手动配置 CLASSPATH。绝大多数现代开发场景下，显式设置 CLASSPATH 不仅没必要，还容易引发类加载冲突或掩盖真实问题。
CLASSPATH 的原始作用
CLASSPATH 是 JVM 启动时用来定位 class 文件（包括 .class 和 jar 包）的路径列表。JVM 按顺序在这些路径中查找类，找不到就抛 NoClassDefFoundError 或 ClassNotFoundException。
早期（JDK 1.4 及之前）没有自动包含当前目录（.），也没有内置对 lib/ 下 jar 的自动扫描机制，开发者必须靠 CLASSPATH 显式声明：
- 当前目录（否则
java HelloWorld会失败） - 第三方 jar 包路径（如
mysql-connector-java.jar） - 自定义类库目录（如
classes/和lib/）
为什么现在基本不用配了？
JDK 5 起引入了“默认 CLASSPATH”规则：
- 命令行未指定
-cp或-classpath时，JVM 默认使用.（当前目录） -
java -jar xxx.jar会自动读取 jar 包内META-INF/MANIFEST.MF中的Class-Path条目，无需外部 CLASSPATH - 构建工具（Maven、Gradle）和 IDE（IntelliJ、Eclipse）完全接管类路径管理，它们生成运行命令时会自动拼接完整 -cp 参数
换句话说：你写的每个 java -cp "a.jar:b.jar:." MyApp，本质就是临时覆盖 CLASSPATH；而设成全局环境变量反而会让所有 java 命令都带上它，容易污染不同项目。
什么情况下仍可能看到 CLASSPATH 配置？
极少数遗留系统或特殊部署环境仍会用到，比如：
- 老版本 Web 容器（如 Tomcat 6 以前）依赖 CLASSPATH 加载共享库（现推荐放
tomcat/lib或应用WEB-INF/lib） - 某些嵌入式脚本或批处理（Windows
.bat）为兼容旧习惯保留了 set CLASSPATH=… - 教学演示刻意展示类加载机制（例如对比有无 CLASSPATH 对
javac/java的影响）
但这些都不是开发实践推荐做法——更安全、清晰的方式是：每次运行明确用 -cp，或交给构建工具管理。
一个常见误区：误配 CLASSPATH 导致的问题
新手常犯的错误是把 JDK 的 lib/tools.jar 或 rt.jar 加进 CLASSPATH。这会导致：
- JVM 尝试从 tools.jar 加载核心类（如
String），触发 “duplicate class definition” 错误 - 破坏 bootstrap classloader 与 system classloader 的隔离机制
- 在不同 JDK 版本间迁移时出现不可预知的兼容性问题
标准 JDK 自身类库由启动类加载器（bootstrap classloader）负责，绝不能也不需要放进 CLASSPATH。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
