kaptGenerateStubsDebugKotlin 任务耗时异常高通常源于注解处理失败或反复重试，表现为模块加载错误、日志卡住、CPU占用高但无响应；需通过--profile定位耗时，检查处理器版本冲突、依赖声明方式及配置缓存兼容性，并启用kapt调试日志和增大JVM内存辅助排查。
kaptGenerateStubsDebugKotlin 任务耗时异常高
这个任务卡住或耗时远超其他编译任务（比如稳定在 40s+），基本可以锁定是注解处理环节出了问题。它不是单纯“慢”，而是生成 Kotlin 存根（stub）失败或反复重试导致的阻塞。常见现象包括：Could not load module 、控制台反复打印 kapt 相关警告、构建中途无响应但 CPU 占用不低。
排查第一步不是改配置，而是确认它是否真在拖后腿：运行 ./gradlew assembleDebug --profile，打开生成的 HTML 报告，直接搜索 kaptGenerateStubs，看它的“Self time”是否显著高于 compileKotlin 或 javac 任务。如果是，说明问题就在这里。
检查注解处理器依赖与版本冲突
Kotlin 注解处理对依赖版本极其敏感，尤其是混合使用 Java 和 Kotlin 模块时。Room、Dagger、Hilt、Jetpack Compose 的 compose-compiler 等都可能触发此问题。
- 确认所有注解处理器都声明为
implementation或api，而非kapt—— 只有真正需要参与注解处理的才该用kapt块 - 检查
build.gradle中是否存在重复引入同一处理器（如同时通过库传递和显式声明） - 升级到与当前 AGP/Gradle 兼容的最新稳定版：例如 AGP 8.2.2 要求
room-compiler≥ 2.6.0，dagger-compiler≥ 2.49 - 临时移除非核心注解处理器（比如先注释掉
kapt 'com.squareup.moshi:moshi-kotlin-codegen'），观察kaptGenerateStubs是否恢复
启用 kapt 调试日志定位具体失败点
默认日志只报错不指路。kapt 提供了细粒度开关，能暴露真实卡点：
在模块的 build.gradle 的 kapt 块中添加：
android {
...
kotlinOptions {
freeCompilerArgs += [
"-Xjvm-default=all",
"-Xskip-prerelease-check"
]
}
kapt {
arguments {
arg("verbose", "true")
arg("showProcessorTiming", "true")
arg("debug", "true")
}
}
}
再执行 ./gradlew assembleDebug --info，你会看到每一步处理器的启动、输入类扫描、输出生成过程。重点看哪一行之后日志停止刷新——那往往就是某个模块解析失败或反射调用卡死的位置。
配置缓存与增量编译失效会放大 kapt 代价
kaptGenerateStubs 本身不支持完全增量，但它的前置条件（如模块 classpath 构建）若无法复用，就会每次全量重跑。这在开启 org.gradle.configuration-cache=true 后尤其明显——如果项目里用了不兼容的插件（如旧版 gradle-dependency-graph-generator-plugin），配置缓存会静默降级，导致每次构建都重新解析全部 build.gradle，间接拖垮 kapt。
验证方式：构建后检查 gradle-out/configuration-cache/ 下是否有有效缓存文件；或加参数 --configuration-cache-problems=warn 查看警告列表。
真正棘手的是：kapt 的错误常被包裹在 Kotlin 编译器内部，堆栈不带源码行号，且容易因 JVM 内存不足提前 OOM 而不报明确错误。所以别只盯着日志，要配合 --profile 报告 + --info 日志 + -Xmx4g 内存参数三者交叉印证。
