java类加载器与classpath是运行时类定位、隔离与可见性的核心协同机制，前者按双亲委派模型分层加载，后者为其提供搜索路径；classpath仅定义系统类加载器的查找范围，不参与实际加载，且各层加载器仅在其专属路径内搜索。
java 类加载器（classloader）和 classpath 并非简单“路径配置”与“加载工具”的关系，而是运行时类定位、隔离与可见性的核心协同机制。理解它们的联动逻辑，比记住命令更重要。
Classpath 是类加载器的“资源地图”
classpath 本身不执行加载，它只是告诉启动类加载器（如 AppClassLoader）去哪里查找类文件（.class）或资源（如 META-INF/MANIFEST.MF）。JVM 启动时，-cp 或 CLASSPATH 环境变量会初始化系统类加载器的搜索路径列表。
- 路径可以是目录（如
./classes）、JAR 文件（如lib/commons-lang3.jar），或通配符（lib/*，仅支持 Java 6+ 命令行） - 多个路径用分号（Windows）或冒号（Unix/Linux/macOS）分隔，顺序决定优先级：靠前的路径中同名类会被优先加载
- 未显式指定
-cp时，JVM 默认使用当前目录（.）作为 classpath
类加载器按层次委托，但只在 classpath 范围内查找
双亲委派模型（Parent Delegation）决定了加载顺序：应用类加载器 → 扩展类加载器 → 启动类加载器。但每层加载器都只在其**自身负责的 classpath 范围内**搜索——不是全局扫描所有路径。
- 启动类加载器（Bootstrap）加载
JRE/lib/rt.jar等核心类，不依赖用户 classpath - 扩展类加载器（Extension）默认加载
JRE/lib/ext/下的 JAR，也不读取 -cp 设置 - 系统类加载器（AppClassLoader）才是真正解析
-cp的加载器，它的搜索范围 = 你指定的 classpath - 自定义类加载器若未重写
findClass()，通常也会沿用父加载器的 classpath 逻辑，除非显式覆盖资源定位逻辑
常见 classpath 错误本质是加载器视角错位
很多 “ClassNotFoundException” 或 “NoClassDefFoundError” 实际源于类加载器与 classpath 的不匹配，而非路径写错。
- IDE 运行正常但命令行失败：IDE 自动将模块输出目录、Maven 依赖等拼成完整 classpath；而命令行可能只写了主 JAR，漏掉依赖 JAR
-
打包成 fat-jar 后仍报错：Spring Boot 的
LaunchedURLClassLoader会解压嵌套 JAR，此时 classpath 是运行时动态构建的，不等于 MANIFEST 中的Class-Path字段 -
Web 应用中类冲突：Tomcat 的
WebAppClassLoader优先加载WEB-INF/classes和WEB-INF/lib，绕过双亲委派（打破委派以支持 WAR 隔离），此时 classpath 的语义已由容器重新定义
调试技巧：看清哪个加载器在用哪段 classpath
遇到加载问题，别只查路径是否存在，要确认“谁在找、在哪找”。
- 打印当前线程上下文类加载器：
System.out.println(Thread.currentThread().getContextClassLoader()) - 查看类的实际加载器：
System.out.println(String.class.getClassLoader())（返回 null 表示 Bootstrap 加载） - 获取系统类加载器的 classpath 路径：
System.getProperty("java.class.path") - 用
jcmd <pid> VM.native_memory summary</pid>或jstack辅助定位类加载上下文（尤其多 ClassLoader 场景）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
