JarException 是运行时异常而非校验工具，真正校验由 JarFile（verify=true）和 Manifest 机制完成；需手动触发验证并捕获 SecurityException、SignatureException 等具体异常。JarException 本身不是用于校验 JAR 包完整性和签名的工具，而是一个运行时异常类，表示在处理 JAR 文件（如读取清单、解析签名、加载条目）过程中发生了错误。它不主动“校验”，也不会自动检测篡改或签名损坏——而是当校验失败后（例如签名验证失败、MANIFEST.MF 格式错误、签名块被修改），JAR 相关 API 内部抛出 JarException 或其子类（如 SecurityException、SignatureException）。
真正负责校验的是 java 的 jarfile 和 manifest 机制，配合 jvm 的 签名验证流程。如果你希望在下载 jar 后主动确认它未被篡改且签名有效，需手动触发验证逻辑，而不是依赖 jarexception 的存在与否。
1. 下载后立即用 JarFile 打开并强制验证签名
Java 在通过 JarFile 构造器打开 JAR 时，默认会对已签名的 JAR 进行完整性校验（前提是未禁用安全检查）。关键点是：必须使用带 verify = true 参数的构造方法，否则签名验证可能被跳过。
-
new JarFile(jarPath, true)—— 第二个参数为true表示启用验证 - 若 JAR 已签名但签名失效（如 MANIFEST.MF 被改、签名文件被删/损坏、证书过期），会抛出
SecurityException或SignatureException（它们常被包装为JarException） - 单纯内容被篡改（如 class 文件被替换但未签名）也会导致验证失败，因为签名块（.SF/.DSA/.RSA）与实际条目摘要不匹配
2. 检查 Manifest 中的签名摘要是否匹配实际内容
即使不依赖运行时验证，也可手动比对：
- 用
new JarFile(path)（verify=false）读取MANIFEST.MF - 提取每个
Name:条目对应的Digest-值（如Digest-SHA-256） - 重新计算对应 JAR 条目（如
com/example/Main.class）的相同摘要算法值 - 比对是否一致 —— 不一致即说明该文件被篡改
注意：此方式绕过了签名证书链校验，仅验证内容一致性；无法识别“合法签名但证书不受信”的情况。
3. 验证签名证书链和信任锚
签名有效 ≠ 证书可信。还需确认：
- 签名证书是否由受信任的 CA 签发（可通过
KeyStore加载系统/自定义 truststore 检查） - 证书是否在有效期内、未被吊销（需配置 OCSP/CRL，Java 默认不强制检查吊销）
- 可调用
jarFile.getJarEntry("META-INF/*.SF")解析签名文件，再用Signature类验证 .SF 文件本身的数字签名
4. 实用建议：组合校验 + 明确异常捕获
不要只 catch JarException，应覆盖更具体的异常类型：
-
SecurityException：签名验证失败（最常见原因） -
SignatureException：签名格式或解密失败 -
IOException：文件损坏、读取异常（可能间接反映篡改） -
InvalidJarIndexException等子类也属于 JarException 体系，但与安全无关
示例逻辑片段：
try (JarFile jar = new JarFile(jarPath, true)) {
// 验证通过，可继续使用
} catch (SecurityException | SignatureException e) {
throw new RuntimeException("JAR 签名无效或内容被篡改", e);
} catch (IOException e) {
throw new RuntimeException("JAR 文件读取失败（可能已损坏）", e);
}
不复杂但容易忽略：验证行为高度依赖打开方式和 JVM 安全策略。确保没有设置 -Djar.check=false 或自定义了禁用验证的 SecurityManager（现代 JDK 通常已移除，但仍需留意旧环境）。
