--continue可让Gradle在任务失败后继续执行无依赖关系的其他任务，收集所有失败并汇总报告，但不执行失败任务的依赖项。
使用 --continue 让 Gradle 忽略单个任务失败
Gradle 默认策略是“一错即停”：只要任意一个任务执行失败（比如 test 报错、compileJava 编译失败），整个构建立即终止，后续任务全被跳过。这不是 bug，而是设计使然——它能快速暴露问题。但当你想一次性发现所有模块的潜在问题（比如多模块项目里多个子项目的测试都挂了），就得主动绕过这个默认行为。
--continue 就是唯一且直接的解决方式。它不改任务逻辑、不重写插件、也不需要修改 build.gradle，纯命令行开关。
- 它只影响「执行阶段」，不影响配置阶段；配置阶段出错（比如语法错误、
project.ext未定义）仍会中断 - 失败任务的依赖项（
dependsOn）不会被执行，但非依赖路径上的其他任务照常运行 - 所有失败都会被收集，构建末尾统一打印汇总，包括每个失败任务的异常堆栈（加
--stacktrace可看更全） - CI 场景下建议搭配
--no-daemon使用，避免守护进程状态污染下一次--continue构建
--continue 和任务依赖关系的真实表现
很多人误以为 --continue 是“无视所有依赖强行跑完全部任务”。其实不是。Gradle 仍严格遵循 DAG（有向无环图）调度：如果 :app:test 依赖 :app:compileTestJava，而后者失败了，那 :app:test 根本不会启动——哪怕你加了 --continue。
真正能“继续”的，是那些和失败任务没有直接或间接依赖关系的任务。例如：
-
:lib:build和:app:test无依赖 →:lib:build会照常执行 -
:common:jar是:app:compileJava的输入 → 若:common:jar失败，则:app:compileJava不会执行 - 跨项目任务如
:featureX:assembleRelease和:legacy:check独立 → 两者互不影响
所以别指望靠 --continue 强行跑通一条断裂的依赖链；它的价值在于横向扫描，不是纵向兜底。
CI/CD 中怎么安全用 --continue
在 Jenkins、GitHub Actions 或 Azure Pipelines 里硬编码 --continue 很常见，但容易埋坑：
- 它会让构建状态始终返回
BUILD FAILED（即使只是某个非关键任务失败），导致 pipeline 误判为“整体不可用” - 某些平台（如旧版 Azure Pipelines 的
gradle@3任务）默认不透传命令行参数，需显式配置options: '--continue' - 若结合
--scan（Build Scan），失败任务仍会上报，但扫描报告里不会自动折叠失败项，需手动点开看细节 - 不建议在本地开发时长期启用——它掩盖了本该立刻修复的编译/配置错误，拖慢反馈闭环
推荐做法：CI 阶段用 --continue + 解析最终输出里的 FAILED 行数做分级判断；本地调试时禁用，保持“fail fast”节奏。
替代方案？别碰 ignoreFailures 这类伪解法
有人翻文档看到 test.ignoreFailures = true 或 jacoco { ignoreFailures = true }，就以为能全局跳过失败。这是典型误解：
-
ignoreFailures是特定任务类型的内部属性（仅对Test、JacocoReport等少数 Task 类生效），它让该任务自身“不抛异常”，但不改变 Gradle 调度器的行为逻辑 - 它无法作用于
Compile、ProcessResources等基础任务；也不能跨任务传递“容错”语义 - 滥用会导致构建状态失真：比如
test.ignoreFailures = true后，build任务看似成功，但实际测试全挂了却没人告警
真正可控、透明、符合 Gradle 原生模型的，只有 --continue。其他都是补丁，不是解法。
