Gradle 默认在当前项目（含所有子模块）执行任务，但可通过命令行精确指定模块路径，如:web:test；漏掉开头冒号或混入文件系统路径会导致报错；-x可临时排除指定模块任务，dependsOn可跨模块绑定任务依赖。
直接在命令行指定模块路径加任务名
Gradle 默认会在当前项目（含所有子模块）执行任务，但你不需要改任何配置，只要在终端里明确写出模块路径就能精准命中。比如项目结构是 root → :api, :common, :web，你想只跑 web 模块的 test 任务，就运行：
./gradlew :web:test
注意开头的冒号 : —— 这是 Gradle 的模块路径分隔符，:web 表示根项目下的 web 子项目，不是目录名或文件夹名。如果模块嵌套更深，比如 services:auth，就得写成 :services:auth:test。
常见错误现象：
- 输成
./gradlew web:test（漏掉开头冒号）→ 报错Task 'web:test' not found - 输成
./gradlew ./web:test（混入文件系统路径）→ Gradle 根本不识别这种写法 - 在
web目录下执行./gradlew test→ 仍会触发所有模块，因为 Gradle 以根目录的settings.gradle为准，不看当前 shell 路径
用 -x 排除其他模块的默认任务
当你在根目录运行 ./gradlew test，Gradle 会按 settings.gradle 里声明的顺序依次执行每个子项目的 test 任务。想“保留 A 模块测试、跳过 B 和 C”，最轻量的方式是排除：
./gradlew test -x :b:test -x :c:test
这里 -x 是 exclude 的缩写，后面必须跟完整任务路径（带冒号前缀）。它不会禁用任务本身，只是让 Gradle 在执行 DAG 时跳过这些节点。
使用场景：
- 临时调试：不想改脚本，快速绕过某个慢/不稳定的模块测试
- CI 分阶段执行：先跑核心模块，再单独触发外围模块
- 避免副作用：某模块的
test会启动 DB 容器，而你本地没配好
注意：-x 只影响本次命令，不改变构建逻辑；它也不能排除子任务（比如 :b:test 里的 :b:compileTestJava），那些仍会照常执行——因为它们是依赖项，不是被显式排除的目标任务。
在 build.gradle 里用 dependsOn 绑定跨模块任务
如果你希望每次执行 A:test 时，自动也跑 B:integrationTest（但不跑 B:test），就得在 A/build.gradle 里显式声明依赖关系：
test.dependsOn ':b:integrationTest'
这样 ./gradlew :a:test 就会先执行 :b:integrationTest，再执行 :a:test。关键点在于：
-
dependsOn接受字符串路径，不是项目对象引用 - 目标任务必须已存在（即
B模块里确实定义了integrationTest这个任务） - 如果
B模块没启用java-test-fixtures或自定义任务，integrationTest就不会自动注册——得先在B/build.gradle里tasks.register('integrationTest', Test)
容易踩的坑：在 A 里写 test.dependsOn tasks.findByName('integrationTest') 会失败，因为该任务属于 B 项目，不在 A 的 task scope 里。
test 任务默认作用域是每个子项目独立的
这是最容易误解的一点：你在 A/build.gradle 里写 test { excludes = ['**/SlowTest.class'] }，只过滤 A 自己的测试类，对 B 模块的 test 任务完全无效。Gradle 的每个子项目都有自己的 test 实例，配置不共享。
所以“从主模块控制子模块测试行为”的本质，不是靠配置继承，而是靠：
- 命令行路径精确寻址（
:b:test） - 任务图显式连接（
dependsOn/mustRunAfter） - 外部排除开关（
-x）
真正需要统一管理测试策略时，别试图在 A 里硬控 B，而是把规则下沉到 B 自身的任务定义里——比如让 B 提供 fastTest 和 fullTest 两个任务，A 只负责调用哪个。
