classpath本质是jvm运行时查找.class和资源文件的搜索范围，按应用类路径、扩展类路径、启动类路径优先级合并；仅作用于java命令执行阶段，不参与编译，且严格从左到右匹配首个命中项。
Java 的类加载路径（ClassPath）本质是 JVM 运行时查找 .class 文件和资源文件（如 .properties、.xml）的搜索范围，它不参与编译过程，只在 java 命令启动时起作用。JVM 不会遍历整个磁盘，而是严格按预设路径列表从左到右依次查找，找到第一个匹配的类就停止加载——不会继续往后找同名类。
ClassPath 的三层来源与优先级
JVM 实际使用的 classpath 是三部分合并的结果，按加载优先级从高到低排列：
-
应用类路径（Application Classpath）：开发者控制的部分，包括
-cp指定的路径、MANIFEST.MF中的Class-Path、或环境变量CLASSPATH；这是你日常配置的重点 -
扩展类路径（Extension Classpath）：默认为
$JAVA_HOME/jre/lib/ext（JDK 9+ 已废弃，由模块系统替代）；普通项目基本不用动 -
启动类路径（Bootstrap Classpath）：包含
rt.jar等核心类库，由 JVM 内置决定；无法被-cp覆盖，即使你放一个自己的String.class也不会被加载
查找 .class 文件的具体规则
JVM 按照“路径列表 → 目录结构 → 包名映射”三级匹配：
- 路径列表中每个条目可以是目录（如
classes/）、JAR 文件（如lib/commons-lang3.jar），或通配符（如lib/*，仅匹配 JAR，不递归子目录） - 对于目录条目，JVM 会按包名层级展开查找：比如类
com.example.User，就在该目录下找com/example/User.class - 对于 JAR 条目，JVM 解压读取其内部结构，同样按
com/example/User.class路径匹配；JAR 内的META-INF/MANIFEST.MF中还可声明额外依赖路径 - 多个路径用
:（Linux/macOS）或;（Windows）分隔，JVM 从左到右扫描，先出现的路径中若存在目标类，后续路径中的同名类将被忽略
常见误区与验证方法
很多 NoClassDefFoundError 或 ClassNotFoundException 并非代码写错，而是 classpath 配置偏差：
- 路径含空格未加引号，Shell 会错误拆分参数；Windows 下写错分隔符（用了冒号）会报“无法识别的选项”
- 用
java -cp lib/* MyApp时，*只展开当前目录下的 JAR，不包含lib/sub/xxx.jar - 带 package 的类不能直接在当前目录运行：
java com.example.Main要求 JVM 在 classpath 某个根目录下能找到com/example/Main.class，不是在当前目录找Main.class - 验证实际生效的 classpath：运行
java -verbose:class -cp "your-path" YourMain，观察输出中类是从哪个 JAR 或目录加载的
现代开发中怎么处理
手动拼接 classpath 在 Maven/Gradle 项目里已成历史：
- Maven 编译后把
src/main/java输出到target/classes，资源复制到同目录；测试时自动加入target/test-classes - IDE（如 IntelliJ）不操作系统
CLASSPATH变量，而是通过项目结构配置依赖，最终生成带完整-cp参数的启动命令 - Spring Boot 打包为可执行 JAR 后，使用自定义类加载器解压并加载
BOOT-INF/lib/下的依赖，屏蔽了传统 classpath 复杂性
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
