运行 gradle init 前须确认：目录为空或无 Gradle 配置文件；非 Maven 项目需显式指定 --type；JDK 已安装且 JAVA_HOME 指向 JDK 而非 JRE；Gradle 版本需较新。
直接用 gradle init 就能生成标准项目，但必须注意：它不自动创建目录，也不检查当前是否为空；如果目录里已有文件（尤其是 build.gradle 或 settings.gradle），init 会失败或覆盖出错。
执行前必须确认的三件事
运行 gradle init 前，当前目录得是空的，或者至少不含 Gradle 配置文件。否则你会看到类似错误：
Could not initialize class org.gradle.internal.extensibility.DefaultConvention
常见误操作包括：
- 在已有 Maven 项目的根目录下直接跑
gradle init—— 它不会帮你转换pom.xml，除非你显式加--type pom - 没装 JDK 或
JAVA_HOME指向了 JRE 而不是 JDK —— init 会卡在 “Starting a Gradle Daemon”，然后报Unsupported Java version - 用系统自带的
gradle命令（比如 macOS Homebrew 装的），但版本太老（java-application 等新类型，会提示Unknown project type
常用 --type 参数和对应生成结构
gradle init 的 --type 决定了骨架内容，不是所有值都可用，取决于你用的 Gradle 版本（2026 年主流推荐用 8.10+）：
-
--type java-application：生成含src/main/java、src/test/java、App.java入口、runtask 的可执行 Java 项目 -
--type java-library：无 main 方法，带jartask 和默认单元测试结构，适合写 SDK -
--type basic：最简，只生成settings.gradle+build.gradle+ wrapper，适合手动搭框架 -
--type pom：需当前目录有pom.xml，它会读取依赖和模块名，生成等效 Gradle 结构（但不会迁移 profile 或 plugin 配置）
执行后你会立刻看到 build.gradle 里已预设好 java 插件、源码集路径、JUnit 5 依赖 —— 不用再手写 plugins { id 'java' }。
为什么推荐用 ./gradlew init 而不是 gradle init
直接调 gradle init 用的是本地全局 Gradle，版本不可控；而 ./gradlew init 会先下载并使用项目声明的 Gradle Wrapper 版本（由 gradle/wrapper/gradle-wrapper.properties 指定）。这能避免：
- 团队成员 Gradle 版本不一致导致
init生成的 DSL 语法不兼容（比如 Groovy vs Kotlin DSL 默认选择不同） - CI 环境中因缺少全局 Gradle 而失败
-
init生成的gradlew脚本本身被旧版 Gradle 错误重写
如果你还没 wrapper，就先跑一次 gradle wrapper（它本身是 init 插件的一部分），再用 ./gradlew init。
init 后必须马上做的两件事
生成完别急着写代码。有俩坑几乎必踩：
-
build/libs/*.jar运行时报no main manifest attribute：因为java-application类型默认没写Main-Class到 MANIFEST —— 必须手动在build.gradle末尾加：
jar {
manifest {
attributes 'Main-Class': 'App'
}
}
- 想用 JUnit 5 但 test 任务失败：init 默认配了
testImplementation 'org.junit.jupiter:junit-jupiter'，但没开useJUnitPlatform()—— 得在testblock 里补上：
test {
useJUnitPlatform()
}
这两处不改，./gradlew run 和 ./gradlew test 都会直接挂。
