Java类加载顺序为：启动类加载器→扩展类加载器→应用类加载器，且遵循双亲委派模型；启动加载JAVA_HOME/jre/lib下核心类，扩展加载lib/ext（JDK9+废弃），应用加载-cp指定路径、CLASSPATH或当前目录，从左到右查找首个匹配类。
Java 程序运行时，类路径（Classpath）决定了 JVM 从哪里加载类文件。搜索顺序不是随意的，而是严格遵循规则——理解它能帮你快速定位 NoClassDefFoundError、ClassNotFoundException 或版本冲突问题。
启动类加载器（Bootstrap ClassLoader）优先加载核心类
这是最顶层的类加载器，由 C++ 实现，不继承自 java.lang.ClassLoader。它负责加载 JAVA_HOME/jre/lib 下的关键资源：
-
rt.jar（Java 8 及之前，含java.lang.*、java.util.*等所有标准 API） -
resources.jar、charsets.jar、ext/*.jar（部分扩展，但注意：JDK 9+ 中ext机制已被模块系统替代） - 这些路径由 JVM 内置决定，无法通过
-cp或CLASSPATH覆盖；即使你在 classpath 中放了同名的String.class，也不会被加载
扩展类加载器（Extension ClassLoader）次之，加载 lib/ext
它由 sun.misc.Launcher$ExtClassLoader 实现，父加载器是 Bootstrap。默认扫描：
-
JAVA_HOME/jre/lib/ext目录下的所有 JAR 文件（Java 8 及更早） - 可通过
-Djava.ext.dirs=...系统属性覆盖该路径（不推荐，易引发兼容性问题） - 注意：JDK 9 引入模块系统后，
ext机制已废弃；若用--module-path启动，则此阶段不生效
应用类加载器（Application ClassLoader）最后加载用户类
也称系统类加载器（sun.misc.Launcher$AppClassLoader），负责加载用户指定的类路径。其搜索顺序为：
立即学习“Java免费学习笔记（深入）”；
- 先检查
-cp（或-classpath）参数显式指定的路径 —— 这是最常用、最高优先级的用户级控制方式 - 若未指定
-cp，则回退到环境变量CLASSPATH的值（Windows/Linux 均有效，但建议避免依赖它，因易受污染） - 若两者都未设置，则默认使用当前目录（
.） - 路径内多个条目用
:（Linux/macOS）或;（Windows）分隔，JVM 从左到右依次查找，找到第一个匹配的类即停止（不会继续向后搜索同名类）
双亲委派模型决定实际加载行为
类加载并非简单按路径顺序“扫描”，而是通过双亲委派（Parent Delegation）机制执行：
- 每个类加载器在接到加载请求时，先委托给父加载器尝试；只有父加载器无法加载（返回
null），才自己查找 - 因此，即使你在
-cp中放入了javax.servlet.HttpServlet.class，只要它已在rt.jar或模块中存在，就不会被你的版本加载 - 打破委派（如自定义类加载器重写
loadClass()）需谨慎，否则可能破坏类型一致性（例如两个String类被视为不同类型）
掌握这个顺序，你就知道为什么改了 CLASSPATH 没生效、为什么旧版 JAR 覆盖不了新功能、以及为何 java -cp lib/a.jar:lib/b.jar MyApp 中 a.jar 的同名类总被优先使用。关键不在“加了什么”，而在“谁先看到、谁有权加载”。
