只需修改gradle-wrapper.properties中的distributionUrl即可生效，Gradle Wrapper仅依赖该文件中的URL，不支持自动发现或脚本干预；必须使用HTTP/HTTPS地址，禁用file://协议，且需转义斜杠、校验ZIP后缀与哈希值。
gradle-wrapper.properties 里改 distributionUrl 就行
Gradle Wrapper 本身不支持“自动发现”或“配置中心式”的发行包地址，它只认 gradle/wrapper/gradle-wrapper.properties 文件里的 distributionUrl 这一行。企业内部如果已部署 Gradle 发行包（比如放在 Nexus、Artifactory 或内网 HTTP 服务上），直接替换这个 URL 即可生效。
常见错误是把路径写成 file:/// 本地路径——Wrapper 不支持本地文件协议，必须是 HTTP/HTTPS 地址。
- 正确示例：
distributionUrl=https\://nexus.internal.company.com/repository/gradle-dists/gradle-8.11-bin.zip - 错误示例：
distributionUrl=file\:///opt/gradle/gradle-8.11-bin.zip（会报Unsupported protocol: file） - URL 中的
/必须用\转义，否则解析失败 - 务必确认 ZIP 包名与实际一致，
-bin.zip和-all.zip不可混用；Wrapper 只识别-bin.zip（除非明确配置了gradle-wrapper.jar的兼容逻辑）
如何验证 distributionUrl 是否真正生效
很多人改完以为就完了，结果 ./gradlew --version 仍去连 services.gradle.org，说明没生效。根本原因是：Wrapper 的 gradle-wrapper.jar 缓存了旧的 URL，或项目用了旧版 Wrapper 脚本。
- 执行
./gradlew --version后，观察控制台第一行是否出现Downloading https://...—— 如果出现，且域名是你内网地址，才算成功 - 如果仍显示官方域名，检查
gradle/wrapper/gradle-wrapper.properties是否被 IDE 自动还原（Android Studio 有时会覆盖该文件） - 强制刷新 Wrapper：删掉
gradle/wrapper/gradle-wrapper.jar，再运行./gradlew --version，它会重新下载并使用新 URL - 注意：
gradlew脚本本身不读取 properties 文件，它只是调用 jar；真正解析distributionUrl的是gradle-wrapper.jar内部逻辑
企业级分发场景下要注意的三个细节
单纯换 URL 是起点，但大规模团队使用时，容易在版本一致性、权限和缓存上翻车。
- 内网地址必须全项目统一，建议通过 CI/CD 模板或脚手架生成
gradle-wrapper.properties，避免手动编辑出错 - 如果内网仓库需要认证（如 Nexus Basic Auth），
distributionUrl无法传凭据——得靠 JVM 系统属性或 wrapper 自定义逻辑，常规做法是让内网服务匿名可读 - Gradle Wrapper 的校验机制（
gradle-wrapper.properties里的distributionSha256Sum）建议开启并同步维护，否则可能被中间人篡改发行包而不自知
为什么不能靠 init.gradle 或环境变量接管 Wrapper 下载
有人试图用 ~/.gradle/init.gradle 或 GRADLE_USER_HOME 干预 Wrapper 行为，这是徒劳的。Wrapper 的下载流程在 Gradle 运行时引擎启动前就完成了，完全绕过所有用户级配置。
它是一个独立的、JVM 启动阶段的引导过程，只依赖：gradle-wrapper.jar + gradle-wrapper.properties + 网络栈。任何构建脚本、插件、settings.gradle 都插不上手。
所以，企业想统一管理 Wrapper 地址，唯一可靠方式就是管控好这两个文件——尤其是 distributionUrl 的生成与分发。其他路径都是障眼法。
