在子模块目录直接运行 ./gradlew 会失败，因其仅存在于根目录且依赖根目录的 gradle/wrapper/ 和 gradle-wrapper.properties；应使用 ../gradlew build 或显式 ../gradlew :app:build 调用根 wrapper。
在子模块目录里直接运行 ./gradlew 会失败
Gradle Wrapper 脚本（gradlew 或 gradlew.bat）默认只存在于项目根目录，它依赖根目录下的 gradle/wrapper/ 子目录和 gradle-wrapper.properties 文件。如果你 cd 进某个子模块（比如 ./app）再执行 ./gradlew build，系统会报错：No such file or directory —— 因为子模块里根本没有 gradlew 文件，也找不到 wrapper 配置。
../gradlew 是最常用且可靠的跨目录调用方式
只要你在子模块目录中，且项目结构是标准的多模块布局（根目录含 gradlew），就用相对路径调用根目录的 wrapper：
-
../gradlew build：在子模块目录中构建当前子模块（Gradle 会自动识别当前工作目录对应的项目路径） -
../gradlew :app:build：显式指定子项目路径，更明确，推荐用于 CI 或脚本中 -
../gradlew --project-dir ../ build：强制把项目根目录设为工作区，等效于回到根目录再执行
注意：../gradlew 在 Linux/macOS 有效；Windows PowerShell 中用 ..\gradlew.bat build，CMD 中同样适用。
为什么不能在子模块里生成独立的 gradlew？
理论上可以，但不推荐，原因很实际：
- 每个子模块都放一套
gradlew+gradle/wrapper/会导致重复文件，git 提交冗余，且版本容易不一致 - Gradle 多项目构建本质是统一协调的：所有子项目共享同一套 wrapper、同一
settings.gradle和全局生命周期 -
gradle/wrapper/中的gradle-wrapper.jar和gradle-wrapper.properties是为整个构建设计的，不是按模块隔离的
换句话说：Wrapper 不是“每个模块一个”，而是“整个项目一个”。它的作用就是锁定**整个构建过程**所用的 Gradle 版本，而不是单个模块的。
IDE 或 CI 中常见误操作：自动切换到子模块目录后忘了路径修正
Android Studio 或某些 CI 工具（如 GitHub Actions 的 working-directory）可能默认把工作目录切到子模块下。此时如果脚本写的是 ./gradlew build，必然失败。解决方法只有两个：
- 改脚本：统一用
../gradlew或显式指定--project-dir - 改环境：在 CI 配置中确保
working-directory指向项目根目录，而非子模块
最容易被忽略的一点是：gradlew 脚本本身不读取当前目录的 build.gradle，它靠 Gradle 的项目发现机制（从当前路径向上找 settings.gradle）来定位项目结构——所以路径错了，整个构建上下文就崩了。
