Gradle依赖校验失败分两类：一是checksum mismatch，表明文件被篡改或下载不完整；二是signature verification failed，说明签名未被信任库认可，需核查signatory声明与本地GPG密钥。
校验失败时先看报错里具体是哪个依赖和哪种验证类型
Gradle 依赖校验失败分两类：一类是 checksum mismatch（校验和不匹配），说明文件内容被篡改或下载不完整；另一类是 signature verification failed 或类似提示（如 Unable to verify signature for ...），说明签名无法被信任库认可。这两类问题的排查路径完全不同，不能混用同一套操作。
关键判断依据在报错日志末尾：如果出现 Expected SHA-256: xxx, but was yyy，就是校验和问题；如果出现 Signature was not verified using a trusted certificate 或提到 PGP、signatory，那就是来源可信性问题——后者才需要核对“可信来源”。
确认依赖是否声明了可信发布者（signatory）
Gradle 从 7.4 起支持通过 signatory 声明可信发布者，这是校验来源的核心依据。不是所有依赖都自带签名，也不是所有仓库都提供签名元数据。你需要手动检查该依赖是否真的发布了签名信息：
- 打开对应依赖的 Maven 仓库页面（例如
https://repo.maven.apache.org/maven2/com/android/tools/build/gradle/8.7.0/） - 查找是否存在
gradle-8.7.0.pom.asc（PGP 签名）或gradle-8.7.0.module中包含signatory字段 - 若没有这些文件，Gradle 就无法执行签名验证，此时启用
dependencyVerification反而会导致构建失败
常见误区：以为只要开了 verification-metadata.xml 就能自动识别所有可信源。实际上 Gradle 不会“猜”谁可信，它只认你明确写进 signatory 的 GPG key ID 或证书指纹。
检查 verification-metadata.xml 里是否真包含该依赖的可信签名
Gradle 的依赖验证靠 gradle/verification-metadata.xml 文件驱动。这个文件不是自动生成的，必须由你或团队主动维护。如果校验失败，第一反应不应该是删缓存，而是打开这个文件查三点：
-
- 该节点下是否有
0xABC123... 0x99E3E9A3B7D0490F） - 该 PGP key 是否已导入本地 GPG keyring（可通过
gpg --list-keys验证）
注意：verification-metadata.xml 中的 pgp 值只是“期望值”，不是“自动下载源”。如果 key 不存在于本地 GPG 环境中，Gradle 会直接拒绝验证通过，哪怕签名本身完全正确。
绕过单个依赖的校验（仅限调试，不可上生产）
当你确认某个依赖确实可信（比如公司内部私有仓库发布的组件），但又没配好签名或暂时无法更新 verification-metadata.xml，可以临时豁免它：
在 gradle/verification-metadata.xml 的
<!-- 豁免 com.example:internal-sdk，避免阻断构建 --> <allow-unsigned group="com.example" name="internal-sdk"></allow-unsigned>
或者更细粒度地跳过校验和（不推荐）：
<!-- 仅跳过 checksum，仍要求签名 --> <allow-checksum-mismatch group="com.example" name="internal-sdk"></allow-checksum-mismatch>
⚠️ 这种写法不会影响其他依赖的验证强度，但必须确保被豁免的依赖来源绝对可控——比如只来自内网 Nexus，且上传流程有二次人工审核。线上构建脚本里出现 allow-unsigned 是安全审计红线。
真正难的从来不是“怎么关掉校验”，而是“怎么让校验稳稳跑起来”。很多团队卡在第一步：没把 verification-metadata.xml 当作和 build.gradle 一样需要版本管理、Code Review 和定期更新的构件。它一旦过期或漏配，就会变成构建流水线里的定时炸弹。
