Gradle用-p参数指定项目根目录，如gradle -p /path/to/project build，该参数必须位于task名称之前；gradlew可跨目录调用但绑定自身项目，多模块项目缺失settings.gradle时-p无效。
gradle命令怎么指定项目根目录
Gradle 默认只在当前工作目录下查找 settings.gradle 或 build.gradle，如果不在项目目录里，直接运行 gradle build 会报错：Could not determine java version from 'xx.x' 或更常见的 Build file '<current>/build.gradle' does not exist</current>。这不是 Java 版本问题，而是 Gradle 根本没找到项目入口。
解决方法是用 -p（project-dir）参数显式指定项目路径：
gradle -p /path/to/your/project buildgradle -p ~/myapp clean test- Windows 下注意路径分隔符不影响，
gradle -p C:\work\demo build同样有效
这个参数必须放在 task 名称之前，顺序错了（比如 gradle build -p /xxx）会被忽略，Gradle 仍按当前目录解析。
使用 gradlew 时能否跨目录执行
可以，但行为略有不同：gradlew 脚本本身是项目绑定的，它会自动定位到自身所在目录的父级作为项目根——也就是说，你从任意位置调用 /path/to/project/gradlew build，它总能正确识别项目结构。
但如果你希望用某个项目的 gradlew 去构建另一个项目（比如复用一套 wrapper 配置），就不能直接硬链，因为 gradlew 内部写死了相对路径逻辑（如 GRADLE_APP_BASE_NAME=../gradle/wrapper/gradle-wrapper.jar）。此时更稳妥的做法是：
- 确保目标项目已有自己的
gradlew，然后完整路径调用：/other/project/gradlew build - 若目标项目没有 wrapper，优先在目标目录运行
gradle wrapper生成后再调用 - 避免用软链接或复制
gradlew到别处，容易因gradle/wrapper/目录缺失而失败
settings.gradle 缺失时 -p 是否还生效
生效，但有前提：项目必须是单模块，且根目录下存在 build.gradle。Gradle 在仅发现 build.gradle 时会自动进入“单项目模式”，无需 settings.gradle。
如果项目是多模块（含子项目），又没 settings.gradle，即使加了 -p，也会报错：Project directory '/xxx' is not a Gradle project. No settings file found.。这时必须补上 settings.gradle，哪怕内容只有 rootProject.name = "myproj"。
常见陷阱：守护进程和缓存污染
用 -p 跨目录执行多次后，Gradle 守护进程可能缓存了上一个项目的配置（尤其是 JVM 参数、插件类加载器），导致后续构建行为异常，比如编译失败但错误堆栈指向无关模块。
遇到这类诡异问题，先试：
-
gradle --stop终止所有守护进程 -
gradle -p /xxx clean清理目标项目自身输出（build/目录） - 不依赖守护进程时加
--no-daemon参数临时验证
真正稳定的做法，是把构建脚本封装成可带路径参数的 shell/bat 脚本，而不是靠人肉记 -p ——路径写错一次，build/ 就可能生成在错误位置，手动清理反而容易漏。
