Gradle 版本升了，Wrapper JAR 和脚本为何还没更新

执行 ./gradlew wrapper --gradle-version ... 后，版本命令已经显示新 Gradle，但 Git 差异里只有 gradle-wrapper.properties，Wrapper JAR 或启动脚本仍是旧的。这不一定是任务没执行，也不必立即删除整个 Gradle 缓存。

第一次任务由升级前的 Gradle 运行。它先把分发地址指向目标版本；下一次 Wrapper 启动才会使用新分发。若希望 Wrapper 自身的 JAR、gradlew 和 gradlew.bat 也由目标版本生成，需要再运行一次 wrapper 任务。

在工作分支中完成第二次生成

先保留原 Wrapper 文件和未提交差异，确认目标 Gradle 与 JDK、插件兼容。下面以已审定升级到 9.8.2 为例；TARGET_SHA256 必须事先设为该目标分发的真实校验值，不能沿用旧分发的值：

./gradlew wrapper --gradle-version 9.8.2 --gradle-distribution-sha256-sum "$TARGET_SHA256"
./gradlew wrapper --gradle-version 9.8.2 --gradle-distribution-sha256-sum "$TARGET_SHA256"

Windows 使用仓库中的 gradlew.bat。两次都保留项目需要的分发类型、镜像地址、认证入口与下载策略，不能为了执行第二次生成顺便切换到另一种未经审定的分发。若项目通过任务配置固定了目标版本，也要确认这份配置不会把第二次生成又改回旧值。

任务会修改项目文件，后一次启动还可能下载新分发，不能把它当只读诊断。第一步若因原 Gradle 与当前 JDK 不兼容而无法运行，应先使用旧版本支持的 JVM 启动，再执行既有升级流程。

审查完整文件集，而不只看版本号

检查 properties 中的目标 URL 和 distributionSha256Sum，连同 Wrapper JAR、两个平台启动脚本一起审查和提交。目标分发的 SHA 与 Wrapper JAR 的完整性校验用途不同，不要把一个值用到另一个位置。原来的重试次数、超时或网络策略若由任务配置管理，也应保持预期。

只有 properties 改动时，旧 Wrapper 往往仍能启动新 Gradle；但这不等于目标版本对启动脚本与 Wrapper 的改进已经落地。反过来，文件哈希变化也不能替代来源核验，不从陌生仓库随手复制一个 JAR 来补齐差异。

最后用仓库 Wrapper 核对实际版本，再从原来的终端、IDE 和 CI 入口执行项目既有构建与测试。保留成套回退提交，回退时连同分发配置和脚本一起恢复，而不是只把一个版本号改回去。