运行这个命令后，经常卡到88%或者94%这种位置，每次都卡在:app:kspAppMaxDebugKotlin，在编译前段Gradle会先执行KSP任务（比如 kspDebugKotlin），也就是说ksp解析就没过。
在这个过程中
它做什么：
1.扫描你代码里的注解（比如 @Entity、@Parcelize），然后生成一堆新的 .kt 文件（比如 UserDao_Impl.kt）。
2.它不管什么：它不负责把 .kt 转成 .class，也不负责资源合并、签名、压缩这些事。
再加上我之前正好在Dao文件加了几个非常非常长SQL语句， 有 30 多个 or like
Room 编译时会生成一个极其复杂的查询计划。对于 SQLite 来说，这种写法会触发 "too many terms in compound SELECT" 之类的内部限制（虽然 SQLite 本身没有硬性限制，但 Room 的代码生成器会对 or 嵌套层级有限制）。
更重要的是，这种全字段模糊搜索在 Android 上根本不可行：
1.30 个 or like全部无法使用索引，全表扫描，每搜索一次都要扫描几千条记录。
2.搜索 30 个字段，每条记录要读取 30 个文本字段到内存进行比较
3.这个 Dao 被多个表使用，每个表都有类似查询，编译时间成倍增长
几十个or like会导致某些版本的 Room parser 会进入指数级分析，可能造成 Room Sql Parser 死循环，真是基础不行地动山摇。
还有一种可能是Room 在推导返回类型，例如：
fun searchAllFieldsAll(): List
Room 会检查：
每一列
nullable
converter
entity
SQL 越长：
SELECT *
虽然最终还是 Entity，
但是解析树非常大。
下面是卡住的情况
.\gradlew.bat assembleAppDebug
Task :app:stripAppDebugDebugSymbols
Unable to strip the following libraries, packaging them as they are: libandroidx.graphics.path.so, libarchive-jni.so, libimage_processing_util_jni.so, librenderscript-toolkit.so, librtmp-jni.so, libsurface_util_jni.so. Run with --info option to learn more.
<===========--> 88% EXECUTING 2m 31s
IDLE
IDLE
IDLE
IDLE
:app:kspAppMaxDebugKotlin
IDLE