Gradle test 一启动就 EOFException，检查上次截断的二进制结果

./gradlew test 还没运行任何测试就报 java.io.EOFException，下一次仍在同一位置失败。若堆栈落在读取上次失败测试的路径，并涉及 build/test-results/<任务>/binary/results-generic.bin，应检查这份历史结果是否被截断。

Gradle 9.8.1 有这条明确路径：文件头还能读出来，但读取后续测试记录时遇到 EOF，任务在重写结果之前就失败。因此反复运行不会自然修好。其他位置的 EOF，例如下载依赖或读取应用文件，不属于这一判断。

先停止共享输出目录的写入

确认 IDE 测试、终端和 CI 没有同时使用同一个工作目录。两个构建写入相同结果文件，是导致文件损坏的一种可能条件，不能仅凭 EOF 就认定一定发生过并发。

保留完整失败日志、文件大小和时间，再将已确认损坏的旧结果复制到项目外的备份位置。测试报告可能包含测试数据、请求内容或路径，按项目要求保存，不要上传到公开日志。

停止相关构建后，将该任务的 results-generic.bin 移出 binary 目录，文件路径以堆栈和任务配置为准。它是上次测试的生成结果，移走会丢失供 Gradle 优先调度失败类使用的历史信息，不会修复测试源码。不要清空整个用户级 Gradle 缓存，也不要移动别的任务正在使用的结果目录。

重新运行原测试任务

用原来的测试参数运行同一个任务。需要看到测试实际开始、测试数量符合预期、新二进制结果能生成；若测试本身失败，应继续处理真正的断言或初始化异常。命令返回非零不必然代表旧结果问题还在，关键是它是否已越过历史结果读取阶段。

若文件再次损坏，先确认独立工作区是否仍共享同一个自定义 binaryResultsDirectory，并检查异常中止、存储空间与构建取消记录。仅把移除文件写成每次执行的 doFirst，会让历史失败排序一直失效，也可能掩盖持续的写入冲突。

确实需要临时自动清理时，应只作用于这个已确认的任务结果，并在没有并发写入的前提下使用；保留去除绕行的条件。正式升级后也要验证完整读取路径，不能只测试空结果或损坏文件头：这次故障恰恰发生在文件头可读、后续记录被截断的情况。

恢复旧文件可保留问题复现线索，但不要把它放回正常工作目录继续阻塞构建。新的有效报告生成后，把调查所需副本单独归档即可。