Gradle 配置阶段读 metadata.bin 失败：定向隔离损坏的缓存工作区

CI 刚恢复 Gradle 缓存，配置项目时就报 Could not read workspace metadata from .../metadata.bin，内部异常是 EOFException、Kryo Buffer underflow 或文件不存在。先看堆栈中的具体缓存工作区，反复重跑可能只是在读取同一份坏数据。

Gradle 8.14.5 的明确故障发生在 DefaultImmutableWorkspaceMetadataStore.loadWorkspaceMetadata。上游缓存解压曾报告 unexpected EOF，后续加载到缺失或截断的 metadata.bin，构建还未进入正常任务执行就中止。该文件不是项目源码，也不是某个依赖 JAR。

按报错路径隔离一条缓存

保存完整日志、缓存恢复记录与对应路径。典型路径包含实际 Gradle 用户目录下的 caches/8.14.5/groovy-dsl/<哈希>/metadata.bin，也可能来自其他不可变工作区类别。不要把示例路径当成所有机器固定位置。

停止使用这份缓存的 Gradle 构建，包括同一 Runner 上的其他任务，再把堆栈所指的整个哈希工作区移到缓存之外的保留位置。只移动 metadata.bin 可能留下不一致的其余产物；隔离单条工作区更便于保持证据和重建边界。

这会使对应脚本或转换重新生成，可能增加构建时间，也可能重新访问依赖仓库。不要删除整个 .gradle、所有项目缓存或本机 Maven 仓库。缓存由其他构建共享时，应先调整作业隔离，不能在它们运行期间动目录。

重新构建并确认该条目重建。如果 CI 随后又从同一个坏归档恢复，应同时更新或失效对应缓存键；本机清理无法修复远端反复下发的损坏归档。先保留取证副本，再按 CI 平台的缓存策略处理。

升级需要连同插件兼容一起看

Gradle 9.4.0 的正式实现已把缺失或截断的这类元数据作为可重新执行的工作区处理。它能改善恢复行为，但从 8.x 迁到 9.x 还涉及插件和构建 API 兼容，不能只改分发 URL 就直接投入发布。

项目暂时留在 8.14.5 时，定向隔离损坏条目与修复缓存恢复链路可以先解决当前故障。若堆栈不是这个元数据加载路径，或文件完整但持续产生其他解析异常，需另查文件系统、磁盘空间和实际 Gradle 版本。

验收应使用原 CI 入口完成一次构建，再保存并恢复新缓存完成下一次。两次都需越过配置阶段，任务与测试结果符合预期。回退 Wrapper 不会自动还原缓存状态；调查副本应独立保存，避免重新注入正常构建目录。