CI上Gradle构建比本地慢的主因是环境配置未对齐，具体包括daemon未复用、构建缓存未启用远程服务、依赖未走内网镜像及构建目录清空导致本地缓存失效。
CI 上 Gradle 构建比本地慢，大概率不是代码或逻辑问题，而是环境配置没对齐——尤其是 daemon、缓存、网络这三块被默认关掉或反复清空了。
检查 gradle --status 确认 daemon 是否真正复用
本地开发时 daemon 通常常驻，但 CI 每次都是全新容器或独立工作区，gradle --stop 或 pkill -f gradle 这类清理脚本一跑，daemon 就彻底失效。冷启动一次可能多花 2～4 秒初始化时间，叠加模块数多的项目，总耗时就明显拉高。
- 在 CI 脚本开头加一句
gradle --status，看输出里有没有正在运行的 daemon 进程 - 如果显示 “No daemons are running”，说明每次都在冷启动；应去掉所有
--stop和 kill 类命令 - 若用 Docker，确保
GRADLE_USER_HOME挂载到持久卷，否则 daemon 启动后缓存和进程状态无法跨构建保留
验证构建缓存（org.gradle.caching=true）是否实际生效
构建缓存开启不等于自动生效：本地缓存只对单机有效，CI 上必须配远程缓存服务（如 Build Cache Server 或 Artifactory 的 Gradle Build Cache），否则 org.gradle.caching=true 在 CI 中只是个摆设，甚至因校验开销反而略拖慢。
- 执行
./gradlew build --scan，打开生成的构建扫描链接，在 “Build Cache” 标签页看命中率（Hit Rate）是否 > 0% - 如果全是 Miss，检查 CI 是否设置了
ORG_GRADLE_PROJECT_org_gradle_caching=true（环境变量优先级高于gradle.properties） - 远程缓存地址必须可写且认证通过，常见错误是 token 过期或权限不足，日志里会报
Could not store entry in remote build cache
对比依赖下载路径：确认 CI 是否走内网镜像而非公网
本地用了阿里云或腾讯云镜像，CI 却直连 mavenCentral() 或 google()，一次全新构建可能触发上千次公网请求——尤其在海外 CI 机器上，DNS 解析+TLS 握手+物理延迟会让每个 POM 下载卡几百毫秒。
- 在 CI 构建日志里搜
Downloading或GET https://，看域名是不是repo.maven.apache.org或dl.google.com - 检查
build.gradle或settings.gradle中repositories块顺序，确保内网 Artifactory 或 Nexus 地址排最前 - 若用 init script 注入镜像（如
~/.gradle/init.d/aliyun.gradle），CI 容器里很可能没这个文件——应改用settings.gradle显式声明
最容易被忽略的一点：CI 构建目录往往默认清空（clean checkout），导致 .gradle/caches 全丢，连本地缓存都用不上。别只盯着 daemon 和远程缓存，先保住这一层最基础的磁盘缓存。如果连 org.gradle.caching=true 都没配，那其他优化全在打地基之前就盖楼了。
