类加载是分阶段、可干预、有委托规则的运行时过程，loadClass() 默认不触发初始化，仅完成加载、验证、准备、解析；初始化需首次主动使用才执行。
类加载不是“一次性读完.class就完事”，而是一套分阶段、可干预、有委托规则的运行时过程。
loadClass() 调用后到底发生了什么？
调用 ClassLoader.loadClass("com.example.User") 并不等于立刻执行静态代码块或初始化类——它只保证走到「加载→验证→准备→解析」，但「初始化」阶段（即执行 ）要等到首次主动使用才触发。
- 常见误判：以为
Class.forName("X")和ClassLoader.loadClass("X")行为完全一样；其实前者默认initialize=true，会触发初始化；后者默认false，跳过初始化 - 典型场景：Spring 的 BeanFactory 在注册 Bean 定义时常用
loadClass预加载类名，但不初始化，避免提前执行静态逻辑或触发依赖加载失败 - 注意陷阱：若类中静态字段被
final修饰且是编译期常量（如public static final int VAL = 100;），则该值在「准备阶段」就直接写入，哪怕没初始化也能取到——这是少数绕过初始化却能拿到值的情况
为什么 new X() 会触发父类初始化，但 X.class 不会？
因为 JVM 规范明确定义了六种「必须立即初始化」的场景，new 指令属于第一类（遇到 new、getstatic、putstatic、invokestatic），而获取 X.class 是对已加载类的引用，不构成触发条件。
- 子类初始化前，JVM 强制先初始化其直接父类（递归向上），但接口不会触发父接口初始化（除非用到其静态字段）
-
X.class只是访问已存在的Class对象，如果该类此前未加载，会走加载流程；但如果已由其他路径加载过（比如被父类引用间接加载），则直接返回，不重复初始化 - 容易踩坑：在静态块里写
System.out.println(Child.class)，看似只是取 class，但若Child尚未加载，就会触发完整加载+初始化流程——这可能造成意料外的静态逻辑执行
自定义类加载器时，defineClass() 和 findClass() 怎么配合？
defineClass() 是 JVM 提供的“字节码落地”入口，真正把 byte[] 变成 Class 对象；而 findClass() 是你该重写的模板方法，负责定位并读取字节流，再交给 defineClass() 处理。
