Gradle传递模块依赖：'implementation'无效但'compile'可用

核心原因是Gradle中implementation和旧compile的依赖可见性规则完全不同：

• 旧的compile配置是传递性依赖：当service用compile依赖lib时，所有依赖service的模块（比如app）都会自动获得lib的依赖，能直接访问lib的类。
• implementation配置是非传递性依赖：service用implementation依赖lib时，这个依赖只会在service内部可见，不会暴露给上层依赖（app），所以app无法直接访问lib的类。

你误以为implementation是compile的直接替代，但实际上compile的真正替代是api配置——api保留了传递性依赖的特性，同时属于Gradle推荐的现代配置。

正确的配置方式 #

方案一（推荐）：调整service模块的依赖配置 #

在service模块的build.gradle中，把对lib的依赖从implementation改成api：

// service模块的build.gradle
dependencies {
    api project(':lib')
}

然后app模块保持implementation project(':service')即可，此时app能正常访问lib的类，同时符合Gradle的现代依赖规范。

方案二（不推荐，仅必要时使用）：app直接依赖lib #

如果app确实需要直接使用lib的类，也可以在app模块中直接添加对lib的依赖：

// app模块的build.gradle
dependencies {
    implementation project(':service')
    implementation project(':lib')
}

这种方式会打破service作为中间层的依赖隔离，可能导致依赖结构混乱，除非有明确需求，否则优先用方案一。

补充说明 #

Gradle引入implementation和api的核心目的是优化构建速度、明确模块依赖边界：

• 用implementation依赖的库，只会参与当前模块的编译，不会影响上层模块，能减少不必要的编译触发。
• 用api依赖的库，会暴露给所有依赖当前模块的上层模块，适合作为模块对外提供的API依赖。

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