buildScript块确定哪些插件、任务类和其他类可用于构建脚本的其余部分。没有buildScript块，你可以使用所有随Gradle附带的东西。如果您还想使用第三方插件、任务类或其他类(在构建脚本中!)，则必须在buildScript块中指定相应的依赖项。

我很欣赏彼得的回答……但是我并没有立即明白答案和文档中强调的构建脚本的其余部分意味着什么。

通常引入依赖功能是为了在Java程序或您可能正在编写的任何其他程序中使用。引入Spring并不是要在构建脚本中使用，而是要在Java程序中使用。将它放在buildscript闭包中可以确保依赖项在gradle构建本身中可用。不是输出程序。

全局级依赖项和存储库部分列出了构建源代码和运行源代码等所需的依赖项。 构建脚本是用于构建的。Gradle文件本身。因此，这将包含创建rpm的依赖项，Dockerfile，以及在所有依赖build.gradle中运行任务的任何其他依赖项

“buildscript”配置部分是针对gradle本身的(即更改gradle如何能够执行构建)。本节通常包括Android Gradle插件。

这有点高，但希望会有所帮助。

对我来说，一旦我开始理解什么是构建块、方法和任务，清晰的区别就开始形成了。语法如何，如何配置等等。我建议你们把这些都看一遍。在此之后，您可以开始理解这种语法。

那么，了解对象构建的类型是非常重要的。gradle (Project类的一个实例)，以便了解在构建中可以有什么。gradle文件。这将回答'buildScript'和其他来自哪里。为了扩展你的功能/特性(比如android)，看看插件是如何帮助你的。

最后但并非最不重要的是，这里有一个非常好的教程，讨论了闭包，委托，这是理解脚本所必需的概念。

通过演示Android顶级gradle文件来做更多的解释。

buildscript {
    // this is where we are going to find the libraries defined in "dependencies block" at below
    repositories {
        google()
        jcenter()
        maven { url 'https://dl.bintray.com/kotlin/kotlin-eap' }
    }

    // everything listed in the dependencies is actually a plugin, which we'll do "apply plugin" in our module level gradle file.
    dependencies {
        classpath 'com.android.tools.build:gradle:3.4.2' // this is android gradle plugin
        classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version" // kotlin gradle plugin
    }
}

模块级gradle文件

apply plugin: 'com.android.application'
apply plugin: 'kotlin-android'
apply plugin: 'kotlin-android-extensions'

什么是“插件”?它们只是实现Plugin接口的java类。在接口下，它有一个方法“apply”，用于添加多个不同名称的任务对象。Task是一个类，我们可以在其中实现工作流。例如，构建任务由构建应用程序的流程组成。

那么，buildscript是做什么的呢?它定义了在哪里找到插件。插件是做什么的?它包含多个任务。task是做什么的?它为我们提供了构建、安装、lint等。

我的理解可能错了。如果你发现任何误导，请不要犹豫纠正我。

buildscript块用于构建脚本，而不是用于gradle构建输出(例如，Android应用程序apk)。在下面的代码示例中，编码代码用于构建脚本，而不是在gradle构建输出程序中;因此依赖项应该添加到buildscript块中。

https://docs.gradle.org/current/userguide/tutorial_using_tasks.html#sec:build_script_external_dependencies

External dependencies for the build script Instead of manipulating the script classpath directly, it is recommended to apply plugins that come with their own classpath. For custom build logic, the recommendation is to use a custom plugin. If your build script needs to use external libraries, you can add them to the script’s classpath in the build script itself. You do this using the buildscript() method, passing in a block which declares the build script classpath. The block passed to the buildscript() method configures a ScriptHandler instance. You declare the build script classpath by adding dependencies to the classpath configuration. This is the same way you declare, for example, the Java compilation classpath. You can use any of the dependency types except project dependencies. Having declared the build script classpath, you can use the classes in your build script as you would any other classes on the classpath. The following example adds to the previous example, and uses classes from the build script classpath.

import org.apache.commons.codec.binary.Base64

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath group: 'commons-codec', name: 'commons-codec', version: '1.2'
    }
}

tasks.register('encode') {
    doLast {
        def byte[] encodedString = new Base64().encode('hello world\n'.getBytes())
        println new String(encodedString)
    }
}

你可以把buildScript块想象成来自Gradle核心的内容，就像已经在Gradle内部的plugins{}块。 所有的插件都来自父build的buildScript。Gradle将在所有嵌套构建中可用。gradle模块。

我相信buildscript{}中的所有内容都可以用于当前的构建脚本本身以及它的所有子项目。

对于在buildscript{}之外的文件中声明的属性，它不会立即对给定项目本身的buildscript可用，而是对其所有子项目可用。

So if you want to declare something and use it for the buildscript itself right away (current buildscript and not just subproject's buildscript), declare them in the buildscript {} for the current project and it also has the side effect to let subproject use it later on. If you just want to declare something globally (for sub-projects's buildscripts) you can declare them directly as ext {} in parent project. The parent project won't be able to use them for itself's buildscript but it will be available all the subproject to use, in or out of the buildscript clause.

例如在父项目中:

ext {
    kotlin_version_XX = '1.7.10' 
}

buildscript {
    ext {
      kotlin_version = '1.7.10' 
    }
    // kotlin_version will be available here since declared in buildscript{}
    classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version" 

    // will NOT be available here -- error due to kotlin_version_XX declared in project 
    classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version_XX" 
}

如果你有一个子项目:

dependencies {
   
    // both kotlin_version and kotlin_version_XX can be used here, since it was declared in parent project
    implementation "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version"
    implementation "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version_XX"
}

buildscript {
    
    // both kotlin_version and kotlin_version_XX can even be used here for subproject's script's use, since it was already declared in parent project
    classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version"
    classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version_XX"
}