自定义ClassLoader加载非CLASSPATH类需重写findClass而非loadClass，手动读取字节码并调用defineClass；须绕过双亲委派、明确路径来源、避免加载核心类，并验证类可用性。
直接用自定义ClassLoader加载非CLASSPATH路径下的类，核心在于绕过默认委托机制、手动读取字节码、调用defineClass生成Class对象。系统类加载器（AppClassLoader）只认CLASSPATH，想加载F盘、临时目录或网络路径的class文件，必须自己控制字节流来源。
重写findClass而非loadClass
自定义加载器应覆盖findClass(String name)方法，而不是loadClass。因为loadClass默认会先委托父加载器尝试加载——这会导致你的非CLASSPATH类被跳过或报ClassNotFoundException。而findClass是留给子类实现“真正加载逻辑”的钩子，JVM在委托失败后才会调用它。
- 在
findClass中解析类名到对应路径，例如将com.example.MyClass转为com/example/MyClass.class - 用
FileInputStream或URL.openStream()读取字节码到byte[] - 调用
defineClass(name, byte[], 0, bytes.length)完成类定义 - 注意：name参数建议传入全限定名，避免后续
getCanonicalName()等方法异常
指定字节码来源路径要明确且可访问
路径不能依赖CLASSPATH，需硬编码或通过构造参数传入。比如支持从磁盘绝对路径（F:/classes/）、相对路径（./custom-libs/）或URL（http://example.com/classes/）加载。
- 读取本地文件时，确保路径末尾带分隔符，并拼接好类名对应的路径结构
- 若用
URLClassLoader，可直接传入new URL("file:///F:/classes/")，它内部已封装了字节码读取和defineClass逻辑 - 网络路径需处理IO超时、重试、缓存等，不建议在生产环境裸用
HttpURLConnection直读
避免双亲委派干扰关键类
默认双亲委派机制会优先让Bootstrap → Platform → AppClassLoader尝试加载，导致你写的类还没机会执行就被系统加载器拒绝（尤其当类名与JDK内置类冲突时）。
- 如需完全隔离，可在构造时传入
null作为parent，表示以Bootstrap为父（慎用，可能引发NoClassDefFoundError） - 更稳妥的做法是显式指定父加载器为
Thread.currentThread().getContextClassLoader()，保持上下文一致性 - 若加载的是工具类或插件类，建议在
findClass开头加判断：if (name.startsWith("java.") || name.startsWith("javax.")) throw new ClassNotFoundException();，防止覆盖核心类
加载后验证类可用性
成功得到Class对象不等于能正常使用。还需检查类是否能实例化、方法能否反射调用、是否链接成功。
- 调用
clazz.getDeclaredConstructor().newInstance()测试无参构造是否可行 - 用
clazz.getClassLoader()确认返回的是你刚创建的加载器实例 - 若抛
NoClassDefFoundError，大概率是该类引用的其他类不在当前加载器可见范围内——需一并加载其依赖，或统一用同一个ClassLoader加载整组类 - 必要时调用
clazz.getProtectionDomain()查看权限域，排查安全限制问题
