./gradlew tasks 仅显示 group 和 description 均非空的常规任务，跳过隐藏、无分组/描述、配置阶段即执行副作用的任务；tasks --all 则强制列出所有已注册任务（含全限定名、内部task），但未必均可执行。
tasks 只显示常规任务，不包含隐藏或配置阶段触发的任务
执行 ./gradlew tasks 时，Gradle 会跳过那些被标记为 hidden = true 或未显式声明为 group 的 task，也**不会列出在配置阶段就已执行副作用的 task**（比如没用 doLast 包裹的打印语句）。它只展示“友好型”任务——即有明确分组、描述、且生命周期行为合规的 task。
常见现象：你刚写好一个 task hello { println "hi" }，运行 tasks 就立刻看到 hi 输出，但这个 task 在列表里却找不到。原因就是它没分组、没描述，还把逻辑写在了配置块顶层，被 tasks 主动过滤掉了。
- 默认只显示
group != null且description != null的 task - 不显示
dependsOn为空、且未被其他 task 引用的孤立 task - Android 项目中，很多构建中间 task（如
:app:compileDebugJavaWithJavac）默认不出现
tasks --all 显示全部 task，包括隐藏、内部、带路径的完整名称
./gradlew tasks --all 会强制遍历 tasks 容器里的每一个实例，不管它有没有 group、是否被标记 hidden、甚至是不是由插件悄悄注册的。你会看到大量形如 :app:generateDebugBuildConfig 这种带项目路径前缀的全限定名 task。
注意：这里列出的 task 不一定都能直接执行。有些是占位符、有些依赖缺失输入、有些仅用于内部调度（比如 validateSigningDebug 要求 signing config 已配置），强行调用会报错。
- 所有 task 都带完整路径（如
:app:assembleDebug），多模块项目尤其明显 - Android Gradle Plugin 注入的 task 全部可见，比如资源处理、AIDL 编译、R class 生成等
- 自定义 task 如果没设
group，也会以other分组出现，但名字可能只是myTask，没有上下文
为什么你的自定义 task 在 tasks 里不显示，但在 tasks --all 里能看见
最常见原因是：你定义 task 时没设置 group 和 description，或者用了错误的执行时机写法。例如：
task hello {
println "configuring..." // ← 这行在配置阶段就执行了，task 本身没行为
}
这种写法导致 task 没实际动作，也不满足 tasks 的展示条件。正确做法是：
task hello {
group = "custom"
description = "Print hello world"
doLast {
println "hello world"
}
}
- 必须显式指定
group（否则归入other，而tasks默认不展开other） -
description是硬性要求，缺了就不会出现在tasks列表中 - 所有业务逻辑必须包在
doFirst/doLast里，不能裸写在 task 闭包顶层
tasks 和 tasks --all 的性能与使用场景差异
tasks 启动快，适合日常快速确认“有哪些稳定可用的入口 task”；tasks --all 启动慢（尤其大型 Android 项目），因为它要解析全部插件注册的 task 并补全路径，但它是排查“某个特定构建步骤是否存在”或“确认 task 全名以便调试依赖关系”的唯一可靠方式。
容易被忽略的一点：Android Studio 的 Gradle 面板（右侧 Gradle 窗口）底层调用的就是 tasks，不是 tasks --all。所以你在 IDE 里看不到的 task，不代表它不存在——只是没被标记为可发现。
- CI 脚本里慎用
tasks --all做自动化判断，输出不稳定且易受插件版本影响 - 调试 task 依赖时，用
./gradlew help --task <taskname></taskname>比tasks --all更精准 - 如果
tasks --all里都找不到你的 task，说明它根本没被注册进tasks容器（比如写在if条件外但条件不成立，或被onlyIf拦截了）
