tasks.register() 中 group 和 description 必须在闭包内显式赋值，不可后续通过 configure 补充；group 决定任务在 gradle tasks --group=xxx 中的分组归属与 ide 折叠结构，description 是 gradle tasks 列表中显示的说明文字，为空则显示为「unnamed」，影响可发现性与协作效率。
tasks.register() 中设置 group 和 description
用 tasks.register() 创建任务时，group 和 description 必须在闭包内显式赋值，不能靠后续 configure 补充（除非你明确需要延迟配置）。
常见错误是写成这样：
tasks.register('deploy') {
doLast { println 'uploading...' }
}
deploy.group = 'deployment' // ❌ 错误：deploy 变量未定义，且 register 返回的是 TaskProvider，不是 Task 实例
正确写法是：
tasks.register('deploy') {
group = 'deployment'
description = 'Upload artifact to internal Maven repo'
doLast { println 'uploading...' }
}
-
group决定该任务出现在gradle tasks --group=xxx的分组里，也影响 IDE Gradle 面板的折叠结构 -
description是gradle tasks列表中显示的说明文字，不设则为空行，容易被忽略 - 这两个属性必须在注册闭包中直接设置；如果用
tasks.named('xxx').configure{...}后续补，只对已存在的任务有效，且无法改变其分组归属（分组只在注册时绑定）
旧版 task 关键字的 group/description 写法差异
如果你还在用 task xxx { ... }（即立即创建模式），语法上更宽松，但已被 Gradle 官方标记为过时（Gradle 8+ 警告，Gradle 9+ 可能移除）。
示例：
task deploy {
group = 'deployment'
description = 'Upload artifact to internal Maven repo'
doLast { println 'uploading...' }
}
- 这种写法会在配置阶段立刻创建 Task 实例，可能触发不必要的初始化（比如读取未就绪的
project.property） -
group和description可以写在闭包任意位置，甚至用it.group = 'xxx'，但语义不如register清晰 - Android Gradle Plugin 8.0+ 已强制要求使用
register，否则某些 DSL（如androidComponents）会失效
为什么 group 不生效？常见排查点
执行 gradle tasks --group=build 却看不到你的任务？大概率是这几个原因：
- 任务名拼错或大小写不一致 ——
gradle tasks --group=Build和--group=build在不同 Gradle 版本行为不同，建议统一小写 - 用了
tasks.create()但没设group——tasks.create('xxx')默认group = null，不会归入任何分组 - 任务被
enabled = false或onlyIf拦截，导致gradle tasks列表里压根不显示（即使设置了 group） - 多模块项目中，在子项目
build.gradle里注册的任务，gradle tasks默认只显示当前 project 的任务；需加-p :submodule或进子目录执行
description 为空时的副作用
description 看似只是提示文字，但它影响实际行为：
- IDEA / Android Studio 的 Gradle 工具窗口中，无 description 的任务会显示为「Unnamed」，难以区分同名任务（比如多个
copy任务） -
gradle help --task xxx输出里，缺失 description 会导致帮助信息干瘪，协作时别人看不懂这个任务到底干啥 - 某些 CI 插件（如 Gradle Profiler）依赖 description 做任务分类统计，空值会导致聚合失败
- 自定义插件中若用
tasks.withType(YourTaskClass)批量配置，description 是唯一可读标识，别指望靠名字判断语义
分组和描述不是“锦上添花”的装饰，而是任务可发现性、可维护性的基础设施 —— 少写一行 description，后期 debug 时可能多花十分钟确认它是不是你想要的那个任务。
