implementation与api的核心区别在于依赖的传递性：implementation仅当前模块编译可见，不传递给下游模块，提升编译速度并降低冲突；api则强制传递依赖，使下游模块可直接使用其类型，但带来版本绑定与兼容性责任。
选错就等于给团队埋雷：implementation 和 api 的核心区别，不在“能不能用”，而在“谁该看到它”。
为什么改用 implementation 会加快编译速度
Gradle 在构建时会分析整个依赖图。如果模块 A 用 api 引入了 okhttp，而模块 B 依赖 A，那么只要 okhttp 的 API 发生变化（比如新增一个 public 方法），Gradle 就必须重新编译 A 和 B —— 因为 B 的编译类路径里有 okhttp。
换成 implementation 后，B 的编译类路径里压根没有 okhttp，所以它的编译不受 okhttp 内部变更影响。
- 只影响当前模块的实现细节（如工具类、网络层封装）→ 用
implementation - 模块本身是给别人当 SDK 用，且对外暴露了某个库的类型（比如返回
Retrofit.Call<t></t>）→ 必须用api - 误把内部工具库（如
commons-lang3）声明为api，会导致所有下游模块都“被迫”继承这个依赖，增加冲突概率
运行时 vs 编译时可见性这个坑很多人踩
很多人以为 implementation 的依赖“运行时也不可见”，其实不是：implementation 的依赖在运行时对所有模块都可用（因为打包进最终 APK 或 fat jar），只是编译期不暴露给下游模块。
这意味着：
- 你在模块 A 里用
implementation 'com.google.code.gson:gson:2.10'，并在 public 方法里返回JsonObject→ 编译失败！因为下游模块看不到 Gson 类型 - 你改成
api 'com.google.code.gson:gson:2.10'→ 编译通过，但下游模块现在也“绑定”了这个 Gson 版本 - 更稳妥的做法是：避免在 public API 中暴露第三方类型，改用自定义 DTO 或接口
Android Library 模块里 api 是默认配置吗
不是。即使你用的是 com.android.library 插件，api 和 implementation 都不会自动生效——你必须显式写出来。
常见误区：
- 以为
android-library模块天然需要把所有依赖设为api→ 错。只有真正被导出的 API 用到的依赖才需要api - 在
build.gradle里混用compile（已废弃）和implementation→ Gradle 7.0+ 会直接报错Unknown configuration: 'compile' - 升级 AGP 后没改依赖写法，导致某些类在 app 模块里突然报
Cannot resolve symbol→ 大概率是原来用compile的地方该换api却写了implementation
最容易被忽略的一点：api 不是“功能更强”，而是“责任更重”。它意味着你主动承担了版本兼容性承诺——一旦你用 api 暴露了一个库，下游模块就能合法地依赖它的任意 public 成员，你再也不能轻易升级或替换它。
