plugins块是应用插件的新方法，它们必须在Gradle插件存储库中可用。apply方法是向构建中添加插件的较老但更灵活的方法。

新的插件方法不能在多项目配置(子项目，所有项目)中工作，但可以在每个子项目的构建配置中工作。

我认为随着功能的发展，插件配置方法将取代旧的方法，但在这一点上，这两种方法都可以同时使用。

正如@cjstehno已经提到的，apply插件是一个遗留的方法，你应该避免。

随着插件DSL的引入，用户应该没有什么理由使用应用插件的传统方法了。这里记录了它，以防构建作者由于当前工作方式的限制而无法使用插件DSL。

使用新的plugins块方法，你可以添加一个插件，并使用可选参数apply来控制何时应用它:

plugins {
    id «plugin id» version «plugin version» [apply «false»]
}

如果你想在插件块中应用一个已经添加但尚未应用的插件，你仍然可以使用遗留方法。例如，在主项目中添加了一个插件xyz，但没有应用，它应该只应用在子项目subPro中:

plugins {
  id "xyz" version "1.0.0" apply false
}

subprojects { subproject ->
    if (subproject.name == "subPro") {
        apply plugin: 'xyz'
    }
}

注意，您不再需要这个版本了。除非你使用的是Core Gradle插件之一，如java, scala，…

在尝试创建Spring Boot应用程序时，我花了一些时间来理解其中的区别，这就是为什么过了一段时间后我又回答了这个问题。下面是使用Spring Boot插件的例子，对我帮助很大:

目前应该使用什么:

plugins {
  id "org.springframework.boot" version "2.0.1.RELEASE"
}

在Gradle 2.1之前使用的:

buildscript {
  repositories {
    maven {
      url "https://plugins.gradle.org/m2/"
    }
  }
  dependencies {
    classpath "org.springframework.boot:spring-boot-gradle-plugin:2.0.1.RELEASE"
  }
}

apply plugin: "org.springframework.boot"

现在(在Gradle 6中)，你可以不使用构建脚本就为插件命名存储库。 在设置。gradle，我们可以添加插件pluginManagement

pluginManagement {
    repositories {
        maven {
            url '../maven-repo'
        }
        gradlePluginPortal()
        ivy {
            url '../ivy-repo'
        }
    }
}

参考:https://docs.gradle.org/current/userguide/plugins.html秒:custom_plugin_repositories

不过，我想指出的是，一个插件不需要远程发布才能使用它! 它也可以是一个未发布的本地可用插件(无论是约定插件还是其他插件)。

如果有人想引用这样一个未发布的本地可用插件， 你必须将它所谓的“构建”包含在所需的组件/构建中(通过settings.gradle(.kts)-file识别)，如下所示:

pluginManagement {
    includeBuild '<path-to-the-plugin-dir-containing-the-settings-file>'
}

完成之后，可以通过pluginId在plugins {}-DSL-block中使用本地插件。

这是使用Gradle插件的两种不同方式。

应用插件的方式:首先从根构建中解决你需要的插件。gradle:

buildscript {
        repositories {
            // other repositories...
            mavenCentral()
        }
        dependencies {
            // other plugins...
            classpath 'com.google.dagger:hilt-android-gradle-plugin:2.44'
    }

然后在构建中。你的Android gradle模块应用插件:

apply plugin: 'com.android.application'
apply plugin: 'com.google.dagger.hilt.android'

插件方式:结合解析和应用在你的根构建。gradle:

plugins {
    // other plugins...
    id 'com.google.dagger.hilt.android' version '2.44' apply false
}

然后在构建中。你的Android gradle模块应用插件:

plugins {
    // other plugins...
    id 'com.android.application'
    id 'com.google.dagger.hilt.android'
}

android {
    // ...
}

如果插件需要一个版本，那么将版本号放在设置中的pluginManagement块中会更安全。Gradle文件，而不是插件块。

我说的更安全是指你不会遇到这样的错误，比如插件请求类路径上已经存在的插件不能包含一个版本。如果你将一个项目包含到另一个使用相同插件的项目中，并且你的插件版本在plugins块中，就会发生这种情况。

所以与其说:

plugins {
    id 'pl.allegro.tech.build.axion-release' version '1.10.3'
}

Do:

plugins {
  id 'pl.allegro.tech.build.axion-release'
}

然后在设置中。gradle文件:

pluginManagement {
    plugins {
        id 'pl.allegro.tech.build.axion-release' version '1.10.3'
    }
}

我要在刚才说的基础上再加上一点。Gradle引入了插件块的概念，作为一种加速和优化构建过程的技术。以下是Gradle的文档说明:

This way of adding plugins to a project is much more than a more convenient syntax. The plugins DSL is processed in a way which allows Gradle to determine the plugins in use very early and very quickly. This allows Gradle to do smart things such as: Optimize the loading and reuse of plugin classes. Provide editors detailed information about the potential properties and values in the buildscript for editing assistance. This requires that plugins be specified in a way that Gradle can easily and quickly extract, before executing the rest of the build script. It also requires that the definition of plugins to use be somewhat static.

这不仅仅是一种处理插件的新方法，也是一种改进构建过程和/或用户编辑体验的方法。

为了使其工作，需要在构建的顶部指定它，但是如果包含buildscript块，也需要在buildscript块之后指定它。为什么呢?因为构建脚本中的代码是按照其编写的顺序计算的。buildscript块必须在计算plugins块之前计算。记住，buildscript块是关于插件环境的设置。因此，插件块必须在buildscript块之后指定。

新的plugins块不仅指定了项目正在使用的插件，而且还指定了该插件是否被应用。默认情况下，plugins块中的所有插件都将自动应用，除非特别声明不应用(即在plugins块中的插件声明后添加“apply false”)。

那么为什么你声明了一个插件却不应用它呢?我认为主要有两个原因:

1.)这样你就可以声明你想要使用的插件的版本。在你声明了一个插件之后，这个插件现在就在“类路径”上了。一旦一个插件在类路径中，你以后应用它的时候就不再需要指定插件的版本了。在多项目构建中，这使得支持构建脚本更容易一些。(也就是说，你只有一个指定插件版本的地方。)

2.) Sometimes, you may have a plugin, that requires certain things defined before they are applied. In that case, you can declare a plugin in the plugins block, and defer the plugin from being applied until after you define the things that the plugin requires as input. For example, I have a custom plugin that looks for a configuration named "mavenResource". In the dependencies block I'll added a dependency like: "mavenResource(maven_coordinate)". That plugin will find all the dependencies contained in the mavenResource configuration and copy the associated maven artifact to the projects "src/main/resources" directory. As you can see, I don't want to apply that plugin until after the mavenResource configuration is added to that project, and the mavenResource dependencies are defined. Hence, I define my custom plugin the plugins block, and I apply it after the project dependencies have been defined. So, the concept that applying a plugin is old style and wrong is a misconception.

Some of you might wonder what it means to apply a plugin. It's pretty straightforward. It means that you call the plugin's apply function passing it the Gradle Project object for the project where the plugin is being applied. What the plugin does from there on is totally at the discretion of the plugin. Most commonly, the apply function usually creates some Gradle tasks and adds them to the Gradle build task dependency graph. When Gradle starts its execution phase, those tasks will get executed at the appropriate time in the build process. The plugin apply function can also do things like deferring some of it work until afterEvaluate. That's a way to allow other things in the build script to be setup even though they are defined later on in the buildscript. So, you might ask why I didn't do that trick in my custom plugin. What I've observed is that the next subproject starts processing after the root project finishes being evaluated. In my case, I needed the resource added before the next subproject began. So, there was a race condition, that I avoided by not doing the afterEvaluate technique and specifically applying the plugin once the things I needed setup was completed.