这里有两件事情在起作用:

There are two things at play here:

1. 声明依赖时api和implementation的分离.简而言之，implementation 范围内的依赖项仅在运行时可见，因为它们是一个实现细节.此类库将在其发布的 Maven 元数据中使用 runtime 范围.文档
中的更多信息
2. 在 Gradle 5.0 之前，Maven 元数据范围 compile 和 runtime 被 Gradle 混合，因此所有 runtime 依赖项确实出现在编译类路径中.Gradle 5 对此进行了更改

1. The separation of api and implementation when declaring dependencies. In short dependencies in the implementation scope are only visible at runtime because they are an implementation detail. Such libraries will use the runtime scope in their published Maven metadata. More information in the documentation
2. Before Gradle 5.0, the Maven metadata scopes compile and runtime were mixed by Gradle and thus all runtime dependencies did appear on the compile classpath. Gradle 5 changes this

因此，当您发布组件时，Gradle 4.x 的限制意味着您的 common 依赖项可用于 app.请注意，如文档所述，迁移到 Gradle 5 将导致那里出现损坏.而当你直接使用项目时，分离是正确的.

So when you publish your component, the limitation of Gradle 4.x means that your common dependencies are available to app. Note that moving to Gradle 5 will cause a breakage there, as documented. And when you use the project directly, the separation is properly enforced.

解决方法是简单地将属于公共 api 的依赖项提升到 common 中的 api 配置和运行时的依赖项，在 app 中声明它们，毕竟它们是它直接需要的.

The fix is to simply promote dependencies that are part of the common api to the api configuration in common and for the runtime ones, declare them in app as after all they are directly required by it.