--info 输出任务输入/输出变化、依赖解析过程、插件应用详情及配置阶段关键事件（如 compileDebugJavaWithJavac 是否跳过），不显示内部调用栈或 JVM/Wrappers 启动细节；--debug 在此基础上增加 Gradle 内部类加载、TaskExecutionGraph 构建、Daemon 通信、ConfigurationCache 序列化及简化堆栈等，日志量大且影响构建性能。
–info 输出哪些内容
--info 会显示任务的输入/输出变化、依赖解析过程、插件应用详情、配置阶段的关键事件，比如 compileDebugJavaWithJavac 是否跳过、processDebugResources 的资源路径变更等。它不打印内部 Gradle 框架调用栈，也不暴露 JVM 级别或 Gradle Wrapper 启动细节。
常见使用场景包括：
- 构建失败时想确认是否因依赖版本冲突导致
resolve阶段异常 - 发现某个 task 被跳过（
UP-TO-DATE），但不确定是输入没变还是缓存误判 - 检查自定义 task 是否被正确配置（比如
doFirst/doLast是否执行）
–debug 输出哪些内容
--debug 在 --info 基础上进一步展开：包括 Gradle 内部类加载、TaskExecutionGraph 构建过程、Gradle Daemon 通信日志、ConfigurationCache 序列化细节、甚至部分 Groovy AST 转换痕迹。它还会默认启用简化的堆栈（相当于隐含 --stacktrace）。
典型问题需要 --debug 才能定位：
- 构建卡在
Configure project :阶段，怀疑是某段build.gradle中的闭包阻塞了配置 - 自定义 Plugin 的
apply()方法中抛出 NPE，但--info只显示 “Failed to apply plugin”，无具体行号 - 使用
configuration-cache时提示Cannot serialize object of type ...，需看完整序列化路径
参数组合的实际影响
单独用 --debug 日志量极大，容易淹没关键信息；而只用 --info 可能漏掉触发条件。推荐按需组合：
- 快速复现问题：先跑
./gradlew build --info，看是否已有足够线索 - 仍无法定位：加
--debug并重定向到文件，避免终端刷屏：./gradlew build --debug > debug.log 2>&1 - 配合
--stacktrace或--full-stacktrace：注意--debug已含简化堆栈，--full-stacktrace仅在需要排查 Groovy 动态方法调用链时才必要 - Android 项目慎用
--debug+assembleDebug：资源编译阶段会打印每个 AAPT2 调用参数，日志可达百 MB 级别
容易被忽略的兼容性细节
Gradle 8.0+ 默认启用 configuration-cache，而 --debug 会强制触发其校验逻辑，可能额外暴露“Configuration cache is not compatible with ...”类警告——这不是错误，但会影响后续构建速度。这类提示在 --info 下通常不出现。
另外，--debug 会显著延长构建时间（尤其首次运行），因为它禁用了部分内部缓存优化路径。调试完记得切回 --info 或默认级别，否则团队 CI 日志会膨胀且难读。
