复杂多模块项目java.lang.NoSuchMethodError异常及Gradle配置问题求助

• 缓存一致性问题：Gradle的构建缓存（包括configuration-cache）可能留存了旧的类依赖关系，重构后方法签名或类位置变更，但缓存未同步更新。尤其是configuration-cache会缓存构建配置状态，重构涉及模块间依赖调整时，旧缓存会导致加载过时类文件。
• 模块依赖冲突：多模块项目里可能存在传递依赖版本不一致，或者重构后某个模块API变更，但其他模块未同步编译，导致运行时加载了旧版本类（比如方法被移除/重命名，但其他模块仍引用旧签名）。
• 增量编译失效：Gradle增量编译可能没正确识别重构带来的变更（比如扩展类移到其他文件，类全限定名变更，但增量编译的变更检测没覆盖到），导致部分模块未重新编译，混合了新旧类文件。
• 类加载顺序问题：多模块场景下，不同类加载器可能加载了不同版本的同一类，比如某个模块build输出里同时存在旧类和新类，类加载器优先加载了旧版本。

• 针对性清理缓存：不用手动删build文件夹，用Gradle命令清理指定模块缓存：./gradlew :module-name:clean，或清理全局构建缓存：./gradlew cleanBuildCache，比手动操作更高效。
• 调整Gradle缓存策略：
  • 暂时保持org.gradle.unsafe.configuration-cache=false，直到重构后的项目配置稳定——configuration-cache对配置变更敏感度极高，重构期间极易出现缓存失效问题。
  • 可尝试禁用单个模块的构建缓存，在对应模块的build.gradle中添加：

    buildCache {
        enabled = false
    }
    

• 强制全量编译：遇到异常时，执行./gradlew clean build --no-build-cache，强制跳过缓存全量编译，确保所有模块都使用最新类文件。
• 检查模块依赖：
  • 用./gradlew dependencies查看各模块依赖树，排查是否存在传递依赖版本冲突，重点关注重构类所在的模块。
  • 确保重构后，依赖该模块的其他模块都正确声明了依赖，未引用过时类路径。
• 优化增量编译：
  • 重构时尽量保持类的全限定名不变；如果必须移动，可在原位置保留转发类并标记@Deprecated，避免其他模块直接报错。
  • 执行./gradlew build --info查看Gradle增量编译日志，定位未被正确触发编译的模块，调整变更检测规则。
• 配置缓存调试：如果必须开启configuration-cache，执行./gradlew build --configuration-cache --info查看缓存命中/失效日志，定位导致缓存异常的配置项，针对性排除。

内容的提问来源于stack exchange，提问作者Renetik