Java中的CLASSPATH用来告诉Java虚拟机在哪里查找用户自定义类和资源文件。在早期Java开发中，很多人会在系统里配置一个全局的CLASSPATH环境变量，把常用jar包路径写进去。但到了今天，这种做法到底还有没有意义，已经成了不少开发者争论的话题。
CLASSPATH的基本作用
当运行java命令启动程序时，JVM需要加载编译后的.class文件或jar包。CLASSPATH就是一组路径集合，JVM会按顺序在这些路径中搜索类。如果不设置，JVM默认使用当前目录。我们也可以用-cp或-classpath参数临时指定。
# 临时指定类路径运行程序 java -cp "lib/foo.jar:lib/bar.jar:." com.example.Main
为什么曾经推荐配置全局CLASSPATH
在还没有成熟构建工具的年代，开发者常把第三方库统一放到一个目录，然后写进系统环境变量，这样每次编译运行都不用重复写路径。典型配置如下：
# Windows下设置系统变量 SET CLASSPATH=C:libsmysql.jar;C:libsutils.jar;.
- 减少重复输入命令参数
- 方便多项目共用基础库
- 入门教程容易统一教学步骤
现代开发中的争议点
构建工具已经接管依赖
Maven和Gradle会在编译、运行、测试阶段自动生成准确的类路径，开发者不需要关心jar包放在哪。例如Maven项目结构约定优于配置：
<dependency> <groupId>org.apache.commons</groupId> <artifactId>commons-lang3</artifactId> <version>3.12.0</version> </dependency>
执行mvn exec:java时，插件会把依赖拼成临时classpath，跟系统变量无关。
全局变量容易引起冲突
如果系统CLASSPATH里写死了旧版本库，而新项目需要新版本，JVM可能优先加载错误版本，导致NoSuchMethodError。这种问题很难排查。
Java模块系统的变化
从Java 9开始引入模块系统（JPMS），使用module-info.java声明依赖，运行时通过--module-path控制，而不是传统CLASSPATH。模块化项目甚至会在存在全局CLASSPATH时给出警告。
// module-info.java示例
module com.example.app {
requires java.sql;
requires org.apache.commons.lang3;
}
实际建议
| 场景 | 是否配置全局CLASSPATH | 理由 |
|---|---|---|
| 学习Java语法入门 | 可不配置 | 用-cp参数更直观 |
| 使用Maven/Gradle | 不需要 | 工具自动管理 |
| 维护老旧脚本项目 | 可临时设置 | 兼容历史启动方式 |
总的来说，现代Java开发不建议再手动配置系统级CLASSPATH。把它留给构建工具和模块系统处理，能让环境更干净，也避免隐式冲突。如果确实要运行零散class文件，用-cp显式声明才是更清晰的做法。
良好的依赖管理不是靠环境变量堆出来的，而是由工具和声明式配置共同保障的。