类加载是分阶段、可干预、有委托规则的运行时过程，loadClass() 默认不触发初始化，仅完成加载、验证、准备、解析；初始化需首次主动使用才执行。
类加载不是“一次性读完.class就完事”，而是一套分阶段、可干预、有委托规则的运行时过程。
loadClass() 调用后到底发生了什么？
调用 ClassLoader.loadClass("com.example.User") 并不等于立刻执行静态代码块或初始化类——它只保证走到「加载→验证→准备→解析」，但「初始化」阶段（即执行 <clinit>）要等到首次主动使用才触发。
- 常见误判：以为
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 是对已加载类的引用，不构成触发条件。
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 子类初始化前，JVM 强制先初始化其直接父类（递归向上），但接口不会触发父接口初始化（除非用到其静态字段）
-
X.class只是访问已存在的Class对象，如果该类此前未加载，会走加载流程；但如果已由其他路径加载过（比如被父类引用间接加载），则直接返回，不重复初始化 - 容易踩坑：在静态块里写
System.out.println(Child.class)，看似只是取 class，但若Child尚未加载，就会触发完整加载+初始化流程——这可能造成意料外的静态逻辑执行
自定义类加载器时，defineClass() 和 findClass() 怎么配合？
defineClass() 是 JVM 提供的“字节码落地”入口，真正把 byte[] 变成 Class 对象；而 findClass() 是你该重写的模板方法，负责定位并读取字节流，再交给 defineClass() 处理。
立即学习“Java免费学习笔记（深入）”；
- 不要重写
loadClass()——除非你要打破双亲委派；标准做法是继承ClassLoader，只重写findClass()，并在里面调用defineClass() -
defineClass()会自动执行验证（可被-Xverify:none关闭），但不会触发初始化；初始化仍需后续显式调用（如Class.newInstance()或反射调用静态方法） - 关键细节：传给
defineClass()的字节数组必须是合法的 class 文件格式，否则抛ClassFormatError；校验失败（如非法指令）则抛VerifyError
真正难的不是记住七个阶段的名字，而是理解哪些动作发生在哪个阶段、谁控制它、以及你在哪一层还有操作空间——比如「准备阶段设初始值」和「初始化阶段赋真实值」的分离，决定了你无法在静态变量声明时依赖尚未初始化的其他类静态字段。
