./gradlew 是项目级构建入口，通过 gradlew 脚本、gradle-wrapper.jar 和 gradle-wrapper.properties 锁定并自动下载指定 Gradle 版本，确保团队、CI 与本地环境完全一致，避免因版本差异导致构建失败或行为不一致。
./gradlew 是你每天第一个要敲的命令，不是 gradle —— 用 Wrapper 才能保证团队、CI、本地环境版本一致。新手不用记几十个命令，先掌握这四个核心任务 + 两个调试参数，就能覆盖 90% 日常开发场景。
必须会的四个基础命令
它们不是孤立的，而是构建生命周期里有明确依赖关系的节点：
-
./gradlew tasks：不运行任何构建，只列出当前项目所有可用任务。第一次进一个新项目，先跑它，比翻文档快十倍；注意看输出里带[default]标记的任务（比如build），那是默认执行入口 -
./gradlew clean：删掉build/目录。别小看它——当你改了build.gradle但编译行为没变，大概率是缓存没清；Android 项目里资源 ID 错乱、R 文件不更新，也常靠它救急 -
./gradlew build：完整走一遍「编译 → 测试 → 打包 → 检查」。它等价于./gradlew assemble check，但新手直接记build更安全；注意：如果测试失败，整个build就中断，不会生成 jar/aar -
./gradlew dependencies：查看依赖树。遇到ClassNotFoundException或版本冲突（比如两个库都拉了不同版的guava），这是第一排查命令；加--configuration runtimeClasspath可聚焦运行时依赖
跳过测试和强制刷新依赖的两种刚需场景
日常开发中，你不可能每次改一行代码都等测试跑完；而国内网络下，依赖卡住是高频问题：
- 跳过测试：
./gradlew build -x test。这不是偷懒，是合理提速；-x后面跟的是任务名，不是阶段名，所以写-x test，不是-x testing；也可组合多个，如-x test -x javadoc - 强制重拉依赖：
./gradlew build --refresh-dependencies。它会忽略本地缓存，重新向仓库发起请求；注意：只对本次构建生效，不会修改gradle/libs.versions.toml或build.gradle里的声明
为什么不用 gradle 而坚持用 ./gradlew
项目根目录下的 gradlew 脚本会自动下载并启动指定版本的 Gradle（版本锁在 gradle/wrapper/gradle-wrapper.properties 里）。你本地装的 gradle 命令版本可能和项目要求的不一致，轻则报错，重则编译出错却找不到原因。尤其在 Android 项目中，Gradle 插件版本（com.android.tools.build:gradle）和 Gradle 自身版本强绑定，错一个就 No signature of method。
真正容易被忽略的是：即使你只敲 ./gradlew tasks，它也会触发一次完整的配置阶段（Configuration Phase），这意味着所有 build.gradle 里的脚本都会被执行——如果有逻辑错误（比如误写了 ext.version = null.toString()），这里就会直接崩，而不是等到 build 时才暴露。
