ClassLoader.loadClass不触发类初始化，Class.forName默认触发初始化，二者在类加载阶段、类加载器来源、异常处理及语义上存在本质区别。
ClassLoader.loadClass 不会触发类初始化，Class.forName 会
这是最根本的区别，直接影响静态块执行、常量赋值、静态字段初始化等行为。很多线上问题就卡在这一步：类加载了但没初始化，结果调用时抛 NullPointerException 或逻辑不生效。
- 使用
ClassLoader.loadClass时，JVM 只完成「加载 + 链接」，跳过「初始化」阶段 -
Class.forName(String)默认调用Class.forName(String, true, ClassLoader)，第三个参数true表示触发初始化 - 如果真需要延迟初始化，可以用
Class.forName(String, false, loader)，效果等价于loadClass
典型场景：SPI 加载实现类时用 loadClass 更安全；而 JDBC 驱动注册必须靠 Class.forName（老版本），因为驱动类的静态块里写了 DriverManager.registerDriver(...)。
类加载器来源不同，容易导致 NoClassDefFoundError
ClassLoader.loadClass 总是用**当前对象所属的类加载器**（即调用方的 getClass().getClassLoader()）；而 Class.forName 默认用**当前线程上下文类加载器（TCCL）**，除非显式传入第三个参数。
- Web 应用中，Servlet 容器（如 Tomcat）会切换 TCCL 到 WebAppClassLoader，此时
Class.forName("xxx")可能成功，但this.getClass().getClassLoader().loadClass("xxx")失败 - OSGi 或模块化环境里，这种差异更明显——一个 bundle 里的类可能对另一个不可见，用错加载器直接报
NoClassDefFoundError - 建议统一显式传参：比如
Class.forName(name, true, Thread.currentThread().getContextClassLoader())，避免隐式依赖
异常处理方式不同，捕获不到 ClassNotFoundException 很危险
ClassLoader.loadClass 在找不到类时抛 ClassNotFoundException；而 Class.forName 抛的是受检异常，必须显式 catch 或 throws。但很多人忽略一点：如果类找到了，但在初始化阶段失败（比如静态块抛异常），Class.forName 会包装成 ExceptionInInitializerError 抛出，而 loadClass 完全不会触发这个阶段，也就不会暴露这类 bug。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
- 开发期测试时用
Class.forName更早暴露初始化错误 - 生产环境做动态加载（如插件系统）时，若用
loadClass后直接newInstance()，可能等到真正调用方法才崩，堆栈还难定位 - 别只 catch
ClassNotFoundException，对Class.forName还得准备处理ExceptionInInitializerError
泛型和返回类型一样，但语义完全不同
两个方法都返回 Class<?>，看起来可以互换，但语义上：loadClass 是“尽力加载”，forName 是“我要这个类，并且现在就要准备好”。编译器不拦你，运行时才打脸。
- 反射调用前习惯性写
clazz.getDeclaredMethod(...).invoke(...)？如果clazz来自loadClass，且该类有静态初始化逻辑，那 invoke 可能失败——不是方法不存在，而是类根本没初始化到位 - Spring 的
ClassUtils.forName内部其实是封装了Class.forName，并做了空字符串/数组等防御，不是简单代理loadClass - Java 9+ 模块系统下，
loadClass受模块导出限制更严格，而forName如果走 TCCL，可能绕过某些检查（但也更不可控）
真正难的不是记哪个抛什么异常，而是想清楚：你到底要“拿到类结构”还是“让类活起来”。前者选 loadClass，后者闭眼用 Class.forName —— 除非你明确知道自己在绕过初始化。
