defineclass调用前需绕过jvm签名验证，应继承classloader而非secureclassloader或urlclassloader，使用protected defineclass(string, byte[], int, int)重载跳过包封与签名校验，解密须在findclass中完成并避免复用jarentry.getinputstream。
defineClass 调用前必须绕过 JVM 的签名验证检查
直接调用 defineClass 加载解密后的字节码时，如果原始 JAR 被 jarsigner 签名过，而解密后字节未重签或校验被触发，JVM 会在 defineClass 内部抛出 SecurityException: class "X" does not match trust level of other classes in the same package。这不是你解密逻辑的问题，而是 ClassLoader.defineClass 默认会委托给 SecureClassLoader 做包封验证（package sealing）和签名一致性检查。
解决方法是：不要继承 SecureClassLoader 或 URLClassLoader（它们默认开启安全检查），而是直接继承 ClassLoader，并手动实现 findClass，在其中调用 defineClass(String, byte[], int, int) 这个最底层的重载——它跳过所有封装/签名校验，只做字节码格式合法性检查（如 magic number、major/minor version）。
- ✅ 正确基类：
class MyDecryptingClassLoader extends ClassLoader - ❌ 错误基类：
extends URLClassLoader或extends SecureClassLoader - ⚠️ 注意：
defineClass(String, byte[], int, int)是 protected 方法，只能在子类中调用；不能通过反射调用，否则会触发 access check 失败
解密时机必须在 findClass 中完成，且不能复用 JarEntry.getInputStream()
JarInputStream 和 ZipInputStream 在读取加密 entry 时，若直接对 JarEntry#getInputStream() 解密，大概率会失败——因为该流已被 JarFile 缓存或绑定到压缩位置，且部分 JDK 版本（如 JDK 8u202+）会对流做隐式校验。更可靠的方式是：用 RandomAccessFile 或完整读取 byte[] 后解密。
典型流程是：先用 jarFile.getJarEntry(name) 获取元信息，再用 jarFile.getInputStream(entry) 读全字节，传入你的解密函数（如 AES-128-CBC），最后把明文字节交给 defineClass。
- ✅ 推荐做法：用
IOUtils.toByteArray(jarInputStream)或Files.readAllBytes(path)读完整密文，再解密 - ❌ 避免做法：对
JarEntry.getInputStream()包一层CipherInputStream后直接传给defineClass—— 它可能读不满、或触发 EOF 异常 - ? 提示：解密密钥不应硬编码，建议从 native library、环境变量或启动参数（
-Dkey=xxx）注入，避免被 dump 出 class 字节码后反推
双亲委派需显式打破，但 System 类和核心类仍要 fallback 给 Bootstrap
自定义 ClassLoader 默认遵循双亲委派，但加密类通常不允许被父加载器提前加载（否则解密逻辑无效）。所以你在 findClass 中必须「先尝试解密加载，失败再 delegate」，而不是反过来。
但注意：像 java.lang.String、java.util.List 这些类绝不能用自己的逻辑加载，否则会触发 NoClassDefFoundError 或 IncompatibleClassChangeError。JVM 要求 bootstrap class 必须由启动类加载器提供。
- ✅ 正确顺序：
if (name.startsWith("com.myapp.")) { return findAndDefineDecryptedClass(name); } else { return super.loadClass(name); } - ❌ 错误顺序：重写
loadClass并全程 bypass 双亲委派（包括java.*） - ⚠️ 关键点：
super.loadClass(name)会走标准委派链，最终交由 Bootstrap 加载核心类；不要自己去defineClassjava.* 相关字节
defineClass 后的类对象无法被序列化或跨 ClassLoader 共享
即使解密成功、类能 new 实例，也会遇到隐性限制：比如该类实现的接口若由另一个 ClassLoader 加载（如 API jar 未加密，但 impl jar 加密），就会报 ClassCastException；又或者该类对象传给 Spring、Log4j 等框架时，因 ClassLoader 隔离导致反射失败。
根本原因是：JVM 中类的唯一性 = 全限定名 + 定义它的 ClassLoader。哪怕字节码完全一样，两个不同 ClassLoader 加载的类也视为不同类型。
- ✅ 缓解方案：把所有依赖接口、注解、DTO 类放在非加密的 common.jar 中，仅业务逻辑类加密
- ✅ 补充方案：用
Thread.setContextClassLoader(this)在关键执行段临时切换上下文类加载器（如调用加密 service 前） - ⚠️ 高危操作：试图用
Unsafe.defineAnonymousClass或Lookup.defineClass替代defineClass—— 它们生成的类无法被常规反射访问，且 JDK 17+ 已限制使用
真正难的不是解密，而是让加密类“自然融入”现有类加载生态。多数失败案例都卡在包可见性、SPI 服务发现、或日志框架的 MDC 传递上——这些地方不会报错，但行为异常，得靠字节码工具（如 jclasslib）确认类是否真由你的 ClassLoader 定义。
