Gradle Wrapper 足以满足绝大多数构建需求，无需本地安装；它自动下载并缓存指定版本，确保环境一致，避免因本地 gradle 命令绕过 Wrapper 导致的版本冲突与构建不一致问题。
gradlew（Linux/macOS）或 gradlew.bat（Windows），并且 gradle/wrapper/gradle-wrapper.properties 文件配置有效，就完全不需要在本地安装 Gradle。Wrapper 会自动下载并缓存指定版本的 Gradle 分发包，后续构建直接复用。
为什么 Wrapper 足够，本地安装反而容易出问题
本地安装 Gradle 后，系统 PATH 中的 gradle 命令可能被意外调用，绕过 Wrapper 指定的版本，导致构建行为不一致——比如 CI 成功、本地失败，或者 Android Studio 提示 DSL 版本不兼容。
- Android Studio 默认优先使用项目里的 Wrapper，但如果你在 Terminal 里手动敲
gradle build（没加w），就会走本地安装的版本 - CI 环境（如 GitHub Actions、Jenkins）通常只依赖 Wrapper，本地装了反而掩盖环境差异
-
GRADLE_HOME和PATH配置错误时，gradle -v显示的版本和实际 Wrapper 运行的版本可能完全不同
什么情况下才需要本地安装 Gradle
真需求极少，仅限以下三类场景：
- 调试 Gradle 插件源码，需要修改 Gradle 本体并重新编译
- 离线环境且 Wrapper 尚未下载过目标版本（此时可提前把
gradle-8.6-bin.zip或-all.zip放进~/.gradle/wrapper/dists/对应哈希目录） - 想快速验证某个自定义 task 的执行逻辑，不想等 Wrapper 首次下载（但更推荐用
./gradlew --no-daemon -Dorg.gradle.internal.http.connectionTimeout=1000加速）
如何确认你正在用 Wrapper 而不是本地 Gradle
最可靠的方式是看命令前缀和输出日志：
- 必须用
./gradlew build（macOS/Linux）或gradlew.bat build（Windows），不能省略w - 首次运行时，控制台会打印类似
Downloading https://services.gradle.org/distributions/gradle-8.6-bin.zip的日志 - 成功后，可在
~/.gradle/wrapper/dists/下看到对应版本的解压目录，里面包含gradle可执行文件 - 执行
./gradlew -v输出的 Gradle version 应与gradle/wrapper/gradle-wrapper.properties中distributionUrl一致
gradle-wrapper.properties 却没清空 ~/.gradle/wrapper/dists/ 里的旧缓存，结果新配置不生效——这时候不是 Wrapper 失效，而是它忠实地复用了已下载的旧版本。 
