gradle-.all.zip 与 .bin.zip 的核心差异在于配套资源：all 版含 src/（完整源码）和 docs/（文档），bin 版仅有 bin/、lib/ 和 init.d/，体积小但不支持 IDE 源码跳转与离线查阅。
gradle-*.bin.zip 和 gradle-*.all.zip 的实际内容差异
区别不在运行能力，而在「构建之外」的配套资源。gradle-*.bin.zip 只含 bin/（启动脚本）、lib/（核心 jar）和 init.d/（空目录），解压后能跑 gradle build，但没源码、没文档、没 Javadoc；gradle-*.all.zip 在此基础上多出 src/（Gradle 自身完整源码）和 docs/（HTML 用户指南 + DSL 参考 + Groovy API 文档），体积通常是 bin 包的 1.8–2.2 倍。
IDE 跳转源码失败或提示 “Cannot find declaration to go to” 怎么办
这是选了 -bin 包最常触发的问题。IntelliJ IDEA 和 Android Studio 默认会尝试索引 Gradle 自身的源码来支持 Ctrl+Click 跳转，若本地只有 -bin，IDE 就找不到 org.gradle.api.Task 这类类的定义。解决方法不是重装 IDE，而是：
- 删掉当前
GRADLE_HOME下的-bin解压目录 - 下载对应版本的
gradle-X.Y.Z-all.zip（比如gradle-8.6-all.zip）并解压到同一位置 - 重启 IDE，它会自动识别新目录里的
src/并重建索引
注意：不要手动把 src/ 复制进 -bin 目录——init.d/ 或 lib/ 下某些 jar 的内部路径引用可能失效。
离线环境构建卡在 “Downloading gradle-X.Y.Z” 怎么破
根本原因常被误判为网络问题，其实是 wrapper 配置指向了远程 URL，而本地又没提前缓存好对应版本。正确做法是两步走：
- 先确认项目
gradle/wrapper/gradle-wrapper.properties中的distributionUrl指向的是https://services.gradle.org/distributions/gradle-8.6-bin.zip还是...-all.zip—— 如果是-bin，离线时只要本地~/.gradle/wrapper/dists/缺这个 zip 就必然失败 - 手动把已下载好的
gradle-8.6-all.zip放进~/.gradle/wrapper/dists/gradle-8.6-all/xxx-hash/（hash 是随机字符串，可新建一个空目录后首次运行 wrapper 触发生成，再替换 zip）
关键点：wrapper 校验的是 zip 文件名和 SHA256，不是后缀类型；-all 和 -bin 的 hash 不同，不能混用。
CI 流水线该用 bin 还是 all
CI 场景优先选 -bin。理由很实在：-bin 体积小、下载快、校验快、解压快，且 CI 环境通常不打开 IDE、不查文档、不调试 Gradle 内部逻辑。但有两个例外必须切 -all：
- 流水线里跑的是自定义 Gradle 插件测试，且测试代码里用了
ProjectBuilder或反射调用了 Gradle 内部类（如DefaultTask） - CI 构建日志里出现
NoClassDefFoundError: org/gradle/internal/reflect/MethodParameters类似报错——这往往是老插件依赖了docs/或src/下的辅助类做运行时分析
真正容易被忽略的是：某些企业内网镜像站只同步了 -bin 包，却没同步 -all，导致你本地配了 -all，CI 却因 404 回退到远程下载，反而更慢。
