答案是签名验证失败型SecurityException，因篡改JAR导致.MF、.SF与.RSA文件校验链断裂，JVM在类加载阶段主动中止加载以保障安全。
当 JVM 加载一个被篡改过的 JAR 包时，如果其签名文件（如 .SF、.RSA、.DSA）与实际 MANIFEST 或类文件内容不一致，就会在类加载阶段抛出 java.lang.SecurityException，典型提示为：
Invalid signature file digest for Manifest main attributes
这不是权限策略问题，也不是安全管理器配置错误，而是 JVM 在验证 JAR 签名完整性时发现校验失败，属于“签名验证失败型 SecurityException”，本质是包来源不可信，JVM 主动中止加载以保障运行时安全。
为什么篡改 JAR 会触发这个异常？
JVM 对已签名的 JAR 包执行强一致性校验：
- MANIFEST.MF 中每项资源（如
Name: com/example/MyClass.class）都附带 SHA-256-Digest 值 -
.SF文件是对 MANIFEST.MF 的摘要签名，由私钥生成 -
.RSA/.DSA是对 .SF 文件的数字签名，用于验证 .SF 未被篡改 - 一旦你修改了 JAR 内部任意 class、资源或 MANIFEST（哪怕只加一个空格），原有摘要就失效，但签名文件没重签 → 校验链断裂 → SecurityException
常见篡改场景与对应表现
以下操作极易导致该异常：
- 用 zip 工具直接向已签名 JAR 添加或替换 class 文件
- 用 jar -uf 命令更新已签名 JAR（未重新签名）
- 反编译后修改字节码再回打成 JAR（未清理旧签名文件）
- 构建工具（如 Maven Shade）合并多个签名 JAR 时保留了冲突的 META-INF 条目
如何确认是签名问题而非其他 SecurityException？
关键看异常消息是否含以下关键词：
Invalid signature file digestdigest mismatchsignature file not verified- 异常堆栈中出现
java.util.jar.JarVerifier或sun.security.util.SignatureFileVerifier
只要匹配其中一条，基本可排除策略文件、SecurityManager、反射限制等干扰因素，直指签名损坏。
修复方式：删签名 or 重签名
两种合法路径，按需选择：
-
删除签名信息（适合开发调试）：用解压工具打开 JAR，进入
META-INF/目录，删除所有*.SF、*.RSA、*.DSA、*.EC文件（保留 MANIFEST.MF 即可），保存后 JAR 变为“未签名”状态，JVM 不再执行签名校验 -
重新签名（适合生产发布）：使用
jarsigner工具配合有效 keystore 重签：jarsigner -keystore mykey.jks -storepass pass123 -keypass pass123 myapp.jar myalias
注意：若原 JAR 依赖强签名机制（如某些 Applet 或 Java Web Start 场景），删签名可能导致功能失效，此时必须重签名。
