CLASSPATH全局设置会破坏Maven/Gradle的类加载逻辑，因其导致路径合并顺序不可控，引发NoClassDefFoundError、NoSuchMethodError等运行时错误，且跨平台分隔符差异和空格问题易致静默失效；推荐用-cp参数替代，优先级高、作用范围精准。
CLASSPATH全局设置会破坏Maven/Gradle的类加载逻辑
现代Java项目几乎都用Maven或Gradle管理依赖，它们在编译、测试、打包阶段会动态生成并精确控制classpath。一旦你设置了全局CLASSPATH环境变量，JVM就会把它和构建工具生成的路径合并——但合并顺序不可控，常导致旧jar、重复类或缺失资源被优先加载。
典型症状包括：NoClassDefFoundError出现在运行时而非编译期、java.lang.NoSuchMethodError（实际是加载了错误版本的类）、甚至单元测试通过但打包后启动失败。
- 构建工具默认不读取
CLASSPATH，但java命令本身会——只要你在终端直接执行java -jar app.jar，它就生效 -
mvn compile通常忽略CLASSPATH，但mvn exec:java可能意外继承它，行为不一致 - IDE（如IntelliJ）有时会“帮忙”把
CLASSPATH注入运行配置，掩盖真实问题
Windows与macOS/Linux的分隔符差异引发静默失效
全局CLASSPATH里混用;和:不会报错，而是直接跳过非法路径段。比如你在Windows上写export CLASSPATH="/lib/a.jar:/lib/b.jar"（用了冒号），bash会把整个值当做一个路径名处理，结果JVM只尝试加载一个叫/lib/a.jar:/lib/b.jar的文件——显然不存在。
反过来，在Windows的cmd里用set CLASSPATH=lib\a.jar;lib\b.jar，到Linux容器里跑同一套脚本就全崩。这种跨平台脆弱性在CI/CD流水线中极难排查。
- 路径中含空格或特殊字符（如
Program Files）时，未加引号的CLASSPATH会被shell截断 -
CLASSPATH=.看似无害，但会让当前目录始终在类搜索最前，可能意外覆盖jar包里的同名类
替代方案：用-cp参数临时覆盖，精准可控
真正需要指定额外类路径时，应该用-cp（或-classpath）参数，它优先级高于环境变量，且作用范围仅限当次命令。
例如调试一个裸class文件：java -cp ".:lib/commons-lang3-3.12.0.jar" MyApp；或者运行脚本时注入：java -cp "$APP_HOME/lib/*:$APP_HOME/conf" com.example.Main。
- Windows下必须用分号：
java -cp ".;lib\gson-2.10.1.jar" MyApp - 通配符
*只匹配jar，不匹配class目录或子目录，别指望lib/*能加载lib/ext/xxx.jar -
-cp和-D选项顺序无关，但必须放在类名之前，java MyApp -cp ...是无效的
JAVA_HOME和PATH才是你应该盯紧的两个变量
CLASSPATH不是必需项，而JAVA_HOME和PATH是刚需。前者让Maven、Tomcat等工具定位JDK，后者让系统找到java和javac。这两个配错，连java -version都会失败；而CLASSPATH配错，往往要等到运行时才暴露，且现象飘忽不定。
绝大多数场景下，删掉CLASSPATH环境变量反而更干净。验证方式很简单：终端执行echo $CLASSPATH（macOS/Linux）或echo %CLASSPATH%（Windows），输出为空就对了。
真正容易被忽略的是：即使你没手动设过CLASSPATH，某些老旧安装包、IDE模板、甚至公司内部脚本也可能悄悄写入——建议每次遇到类加载异常，先查它是否存在、值是什么。
