ClassLoader.loadClass()找不到自定义路径类是因为系统类加载器仅搜索默认路径，遵循双亲委派模型；需用URLClassLoader或重写findClass()实现自定义加载，注意路径格式、字节码加载与defineClass调用。
ClassLoader.loadClass() 为什么找不到自定义路径下的类
直接调用 ClassLoader.getSystemClassLoader().loadClass("com.example.MyClass") 肯定失败——系统类加载器只查 CLASSPATH、-cp 指定路径和 rt.jar 等默认位置，对额外目录完全无感知。这不是 bug，是双亲委派模型的必然行为：它先让父加载器尝试，父不行才轮到自己，而系统加载器的父（平台加载器、启动加载器）更不可能知道你的临时目录。
真正能加载非标准路径类的，是你自己写的子类，且必须重写 findClass(String name)，而不是 loadClass(String name)——后者默认走委派链，你重写它反而容易破坏机制。
继承 URLClassLoader 是最简可行方案
不用从头实现 ClassLoader，直接扩展 URLClassLoader 即可。它已内置了基于 URL 的字节码定位和 defineClass 调用逻辑，你只需把目标路径转成 URL 传进去。
- 确保路径末尾有
/（否则new URL("file:/path/to/classes")会被当文件而非目录，导致getResource()返回 null） - Windows 下路径要转义反斜杠或用正向斜杠：
file:/C:/mylib/classes/，不能写file:C:\mylib\classes\ - 如果类依赖其他 jar，把 jar 文件也加进
URL[]数组，URLClassLoader会自动处理其内部的Class-Path清单项
示例：
立即学习“Java免费学习笔记（深入）”；
File classesDir = new File("/tmp/myapp/classes/");
URL url = classesDir.toURI().toURL(); // 自动处理空格、中文等
URLClassLoader loader = new URLClassLoader(new URL[]{url});
Class<?> clazz = loader.loadClass("com.example.ServiceImpl");
手动实现 ClassLoader 时 findClass() 的关键细节
如果你需要更精细控制（比如从加密 zip 读取、按版本选 class、跳过某些类），就得继承 ClassLoader 并重写 findClass(String name)。注意三点：
- 类名必须转为路径格式：
"com.example.Foo"→"com/example/Foo.class"，再拼到 base dir 后用Files.readAllBytes()加载 - 字节码拿到后必须调用
defineClass(name, bytes, 0, bytes.length)，不能直接 new Class；否则 JVM 不认这个类的ProtectionDomain和签名 - 不要在
findClass里调用super.loadClass()或getClassLoader().loadClass()，这会绕回双亲委派，失去自定义意义
常见错误：ClassNotFoundException 报的是 “com.example.Foo”，但实际抛出点在 defineClass 阶段，因为字节码版本不匹配或校验失败——这时日志里看不到原始异常，要用 getCause() 层层展开。
类加载后如何正确实例化和调用
用自定义加载器拿到 Class 对象只是第一步。接下来：
- 构造实例时，别用
clazz.newInstance()（已弃用且要求无参 public 构造），改用clazz.getDeclaredConstructor().newInstance() - 如果目标类实现了某个接口（如
Processor），用该接口类型接收实例，避免强依赖自定义加载器加载的类类型——否则编译期就报错“找不到符号” - 方法反射调用前，记得
setAccessible(true)绕过封装检查，尤其当方法是private或包私有时 - 加载器本身别提前 close（
URLClassLoader.close()）或置为 null，否则后续getResourceAsStream或再次loadClass会抛IllegalStateException
跨加载器的类对象不能直接转型，哪怕类名、字节码一模一样——JVM 认为它们是不同类。这点极易忽略，直到出现 ClassCastException 才意识到问题不在逻辑，在类加载隔离。
