Gradle Wrapper 更新后 retries 又变成 0，把重试策略写进任务配置

手动把 gradle/wrapper/gradle-wrapper.properties 中的 retries 改成 3，运行 ./gradlew wrapper 或接受自动依赖更新后，它又变成 retries=0。在 Gradle 9.5.1 中，先检查生成任务的配置，不能假定它会原样继承属性文件里的每一项。

gradle-wrapper.properties 是 Wrapper 任务的输出。直接编辑可以影响下一次 Wrapper 下载，但下次重新生成时，任务仍可能按自己的默认值重写它。retries 在这个版本中的默认值是 0，即下载失败后不额外重试。

把项目策略放进 Wrapper 任务

若项目统一使用三次重试、初始退避一秒，可在根项目的 build.gradle.kts 中配置：

tasks.wrapper {
    retries.set(3)
    retryBackOffMs.set(1000)
}

这里的值是示例，可按 CI 的失败处理策略调整。重试会延长网络故障时的等待时间；退避时间会随连续失败增加，不宜无界增大。

一次性更新也可显式传参：

./gradlew wrapper --retries 3 --retry-back-off-ms 1000

这条命令会修改 Wrapper 文件，应在工作分支中运行并审查差异。如果自动更新工具调用的命令不带参数，放进任务配置通常更容易让后续更新沿用同一策略。

上述属性依赖支持它们的 Gradle 版本。维护较旧 Wrapper 的项目先核对当前执行生成任务的版本，不要为了一个属性直接照搬新版本 DSL。

检查生成文件与启动入口

保留修改前的 Wrapper 文件，再执行项目原来的更新流程，核对 retries、retryBackOffMs 和分发地址。若本次还升级了 Gradle，继续检查校验值、脚本和 Wrapper JAR 是否符合项目既有升级流程，并把需要的生成文件一起纳入版本控制。

使用仓库里的 ./gradlew，不要用 PATH 中另一个 Gradle 来判断项目配置是否生效。下载重试只处理短暂网络失败，不能修复错误 URL、无权访问、代理认证或校验和不匹配；这些错误仍需按具体原因处理。

验收要再走一次实际自动更新入口，确认重试配置不会再次归零。原本失败的网络路径也要按 CI 允许的方式复查，检查失败后确实有限次重试、最终仍能明确退出；无需人为关闭校验或删除全部下载缓存来制造成功。