gradle控制任务执行顺序的核心机制包括：1.dependson（强制依赖，被依赖任务必执行）；2.mustrunafter（仅约束顺序，不强制执行）；3.shouldrunafter（宽松顺序提示，可能被忽略）；4.finalizedby（确保收尾动作在任务执行后无论成败都运行）。
Gradle 中控制任务执行顺序，核心是靠明确的任务依赖关系和排序规则。不是所有“想让 A 在 B 后面执行”的场景都该用 dependsOn；选对机制，才能既满足逻辑又不引入不必要的强制执行。
dependsOn：最常用、最严格的依赖方式
它表示“必须先完成被依赖任务，当前任务才能开始”。一旦声明，Gradle 会把被依赖任务加入执行图，哪怕你只调用当前任务，也会连带执行它。
-
写法灵活：可在任务定义时用参数（
task C(dependsOn: ['A', 'B'])），也可在任务体内赋值（dependsOn = ['A', 'B']），或外部动态添加（C.dependsOn(A, B)） -
跨模块也支持：比如子项目 task 依赖根项目或其他子项目的 task，写成
dependsOn ':other-module:build' -
注意副作用：如果 A 是耗时清理任务，而你只想运行 B，但 B
dependsOn A，那每次跑 B 都会触发 A —— 这未必是你想要的
mustRunAfter：只管顺序，不管是否执行
它不建立执行依赖，只约束“如果两个任务都被选中执行，那必须按指定顺序来”。适合那些逻辑上需先后，但又不该强制拉起对方的场景。
-
典型用例：比如
build.mustRunAfter clean，意思是“如果同时执行 clean 和 build，clean 必须先跑”；但单独执行gradle build，clean 就不会运行 -
支持多种引用方式：可传任务实例、任务名字符串，甚至符合
dependsOn()规则的任意标识 - 不解决循环：如果规则导致环形排序（比如 A mustRunAfter B 且 B mustRunAfter A），Gradle 会报错
shouldRunAfter：宽松的顺序提示
它比 mustRunAfter 更弱，仅作为调度建议。在并行执行或依赖已满足时，Gradle 可能忽略它。
- 适用场景：日志归档、报告生成等“最好晚点做，但早做也不影响结果”的任务
-
会被跳过的两种情况：一是规则本身形成循环；二是当前任务的所有硬性依赖（如
dependsOn）都已完成，即使shouldRunAfter的任务还没跑，它也可能提前执行 - 不改变执行计划：它不影响哪些任务会被执行，只微调调度器的决策倾向
finalizedBy：确保收尾动作一定发生
和前面几种不同，它表达的是“无论成功失败，我之后一定要执行你”。常用于清理、上传、通知等兜底操作。
- 典型搭配：测试任务后自动发送报告，或构建失败后自动删除临时目录
-
链式支持：一个任务可被多个任务
finalizedBy，也可finalizedBy多个任务 - 独立于依赖图：即使被 finalizing 的任务没被选中执行，它的 finalizer 也不会运行；只有当它实际被执行了，finalizer 才会触发
