并行构建未提速，大概率因模块间存在显式或隐式依赖，导致Gradle无法真正并行；必须协同启用构建缓存、配置缓存和守护进程，否则单开org.gradle.parallel=true无效。
并行构建没提速，大概率是模块间依赖太紧
Gradle 的 org.gradle.parallel=true 只对「无直接或隐式依赖」的模块生效。如果模块 A 在 build.gradle 里用 implementation project(':module-b') 显式声明了依赖，那它不会和 B 并行；更隐蔽的是，A 通过反射、Class.forName 或 classpath 扫描加载了 B 的类，但没在依赖中声明——这种隐式耦合会让 Gradle 误判为“必须串行”，实际仍排队执行。
实操建议：
- 用
./gradlew --dry-run assembleDebug看任务执行顺序，确认真正被并行的任务是否符合预期 - 检查各模块的
build.gradle是否存在未声明的跨模块引用（比如 common 模块被多个 module 直接 new 实例但没加 dependency） - 在
settings.gradle中显式定义模块层级，避免include ':lib:network'和include ':app'之间出现意外的 transitive 依赖链
配置开了但没生效，先查 gradle.properties 加载路径
Gradle 会按顺序读取多个 gradle.properties：用户主目录（~/.gradle/gradle.properties）、项目根目录、命令行传入参数。如果主目录里有同名配置且值为 false，就会覆盖项目里的 true 设置。
验证方式：
- 执行
./gradlew properties | grep parallel，看输出是否为org.gradle.parallel=true - 删掉
~/.gradle/gradle.properties中所有与 parallel、caching、daemon 相关的行，只保留项目级配置 - CI 环境中注意是否用了
--no-daemon或GRADLE_OPTS覆盖了 JVM 参数，这类设置会禁用 daemon 进而让 parallel 失效
并行只是提速一环，缺了缓存就等于白开
开启 org.gradle.parallel=true 后，若每次构建都从零开始解析脚本、下载依赖、编译全部源码，那并行省下的几秒会被配置阶段几十秒吞掉。尤其在多模块项目中，配置阶段耗时常占总时间 30% 以上。
必须配套启用：
-
org.gradle.caching=true：复用 task 输出（如compileJava结果），避免重复编译 -
org.gradle.configuration-cache=true：跳过 build script 解析，大型项目可省 20～40 秒 -
org.gradle.daemon=true：复用 JVM 进程，否则每次都是冷启动，parallel 没机会跑起来
这三个配置不全开，单开 parallel 基本等于给一辆没油的车换轮胎。
线程数设太高反而拖慢，得看机器真实负载
org.gradle.workers.max=8 在 8 核 CPU 上合理，但在 CI 容器或 Mac M1/M2 上可能引发资源争抢。实测发现：当系统整体 CPU 使用率持续 >90%，或频繁触发 GC 时，并行任务会因线程切换和内存竞争变慢。
调优建议：
- 本地开发用
org.gradle.workers.max=4起步，观察top或活动监视器中的 CPU / 内存曲线 - CI 环境优先用
org.gradle.workers.max=${nproc}（Linux）或$(sysctl -n hw.ncpu)（macOS），别硬写死数字 - Android 项目特别注意
kapt任务：它默认不支持并行，需额外加kapt.use.worker.api=true才能进并行队列
最容易被忽略的是配置缓存兼容性——哪怕只在一个子模块里用了 project.version 这类动态属性，整个配置缓存就会失效，导致并行带来的收益被反复解析脚本吃掉。上线前务必跑一次 ./gradlew --configuration-cache 看报错。
