Spring Boot项目创建的5种方式：从IDEA向导到CLI全攻略

先放个大实话：我在东家带新人这几年，几乎每个刚接触Spring Boot的都会问“到底怎么建一个项目”这个问题。网上一搜答案五花八门，有的让你去官网扒，有的让你用IDEA向导下一步下一步，还有的直接甩一段命令行到终端里跑。看得人更迷糊。

其实归根结底就一句话：Spring Boot项目再花哨，本质也就是一个“构建脚本 + 主启动类 + 各种依赖库”的普通Java工程。不同的创建方式，只是用不同手段把这三件事拼齐而已。这篇我就结合这几年实际敲过的命令、点过的界面、踩过的坑，把常见的五种方式掰开揉碎讲一遍，从最简单的IDEA向导，到最“原始”的手工搭骨架，全部覆盖。不管你是刚入门还是准备给别人讲课，看完基本心里就有底了。

1. 先想清楚一件事：无论哪种方式，最终要拿到的其实是同一个东西

很多教程上来就教你点按钮，却不解释为什么点按钮，结果遇到一次IDEA抽风或者网络超时，整个人就傻在那儿了。所以在动手之前，我觉得有必要先把“目标产物”说清楚。

1.1 Spring Boot项目的三个核心组成

我们可以把一个Spring Boot工程拆成三层看：

• 构建文件：Maven用pom.xml，Gradle用build.gradle。这里声明了项目坐标、JDK版本、依赖框架版本，以及编译打包插件。这是项目的地基。
• 源代码目录：默认就是src/main/java和src/main/resources。Java代码写在前面，配置文件和静态资源放后面。
• 主启动类：一个带着@SpringBootApplication注解的类，里面有main方法，调用SpringApplication.run(...)来拉起整个应用。

平时说的“创建Spring Boot项目”，翻译成大白话就是：把上面这三样东西按照约定好的默认结构摆好。谁帮你摆不重要，方式是工具，产物才是核心。

1.2 五种方式的本质分类

我常把五种方式归成三类，这样记忆负担小：

类型	对应方式	特点
向导类	IDEA内置Spring Initializr、start.spring.io网页端	自动生成，最省心，适合绝大部分业务开发场景
手工类	自己建Maven工程、自己建Gradle工程	完全理解结构，适合深度定制项目和面试开口讲原理
命令行类	Spring CLI	一条命令初始化，适合脚本化批量生成、体验新功能

明白了这个分类，下面每种方式看起来就不再是一个个孤立步骤，而是围绕同一个目标的合理变体。按这个思路去学，后面哪怕出现第六种、第七种创建方式，你也能一眼看穿它属于哪个流派。

2. 方式一：IDEA内置Spring Initializr，日常开发的主力方案

如果你问我个人最推荐哪一种，我会毫不犹豫地说IDEA内置向导。原因很简单：它把“联网拉模板”和“工程导入”做了深度整合，创建一个项目只需要几分钟，全程不需要离开开发环境，而且IDEA对生成结果做了不错的本地化适配。

2.1 完整操作流程

打开IntelliJ IDEA，按下面这个顺序一步步来：

1. 启动界面点击New Project，或者在已打开的项目里依次选择File → New → Project。
2. 左侧类型列表选中Spring Initializr（IDEA新版本里可能直接显示为“Spring Boot”或者左侧栏目里的“Spring”）。
3. 右侧第一栏选SDK，也就是JDK版本。如果你的机器只装了JDK 17，就选17，别硬选21，后面编译会报错。
4. 点击Next，进入项目元信息页面。这一页要填的是Group、Artifact、Name、Package name，这四样后面我会专门讲。
5. 接下来是Dependencies依赖选择页，勾选你需要的starter。新手至少要勾一个Spring Web，否则项目能启动但啥也干不了。
6. 最后设置项目名称和存储路径，点击Finish，IDEA会自动开始联网下载依赖，首次下载耗时较长，耐心等右下角进度条跑完。

2.2 创建时的几个关键参数别乱填

基本每次带人我都得重复念叨这几个字段的含义，因为填错后的返工成本很高：

• Group：一般写公司域名倒序，比如某个团队叫example，域名是example.com，那就写com.example。它对应Maven坐标的groupId，表示项目所属的组织。
• Artifact：模块名，比如user-service、order-api。它对应Maven坐标的artifactId，也是打成Jar包之后的文件名前缀。
• Package name：项目Java代码的根包名，默认会拼成com.example.user-service，但注意：包名里不能有连字符。IDEA通常会自动把连字符去掉，但如果你手工改坏了，后面建类都会报莫名其妙的全限定名错误。合法写法是com.example.userservice。

这里有一个我踩过不只一次的小坑：IDEA自动给出的Location路径偶尔会带有中文或者空格，比如桌面路径如果是“C:\Users\我的名字\Desktop”，某些插件版本在后续构建时会出现路径解析异常。建议项目路径尽量放在纯英文、不含空格的目录下。

2.3 项目生成后建议先做三件事

向导点完后，有经验的开发者不会马上写业务代码，而是先做三个“扫尾动作”：

1. 看一眼Maven仓库是否切换到了公司私服。IDEA默认用的是本地仓库加中央仓库，很多公司内部网络访问中央仓库慢，会卡在依赖下载阶段。
2. 确认src/main/resources下有一个application.properties或application.yml。如果没有，手动建一个，否则后面配置端口、数据库都无从下手。
3. 直接运行一次主类，看到类似“Started Application in X seconds”的日志再关掉。这一步能提前发现JDK版本不匹配、依赖下载失败等环境问题，越早暴露越好。

提示：IDEA自带的Spring Initializr本质上是把官方生成器的逻辑封装进了IDE，所以界面选项和网页版几乎一致。区别仅仅是自动导入更顺滑而已。

3. 方式二：start.spring.io网页端生成，换机器时的稳妥备胎

我为什么说它是“备胎方案”？因为遇到以下情况时，它比IDEA内置向导更靠谱：

• IDEA插件突然装不上，或者公司不允许直接在线访问插件库；
• 你需要在服务器、终端环境或者其他同事的机器上快速生成基础工程；
• 你需要生成多个不同版本的工程，网页端切换更直观。

start.spring.io就是Spring官方提供的在线初始化服务。很多国内教程也管它叫“网页版脚手架”。

3.1 网页端配置流程

打开浏览器访问官方生成器页面（通常就是start.spring.io），会看到一个包含多项表单的页面，流程如下：

1. Project一栏选择构建工具：Maven或Gradle。绝大多数项目用Maven。
2. Language选Java、Kotlin或Groovy。Spring Boot的主流场景还是Java。
3. Spring Boot版本选最新的稳定版本，建议不要选带有（SNAPSHOT）字样的，那是开发中的快照版，稳定性差一点。
4. Group/Artifact填写规则和前面说的一样。
5. Dependencies区域点Add Dependencies，按关键字搜索，比如输入web会弹出一堆包含web的starter，选Spring Web即可。
6. 填写完后点击页面下方的Generate按钮，浏览器会下载一个zip压缩包。

3.2 解压后导入IDEA的两种方式

拿到zip包后，导入IDEA有两条路线：

• 路线一：解压zip，打开IDEA，选择File → Open，定位到解压目录，选中pom.xml文件并点击Open，IDEA会把整个目录识别为Maven工程。
• 路线二：在主界面直接选Open，然后选择zip文件，IDEA会自动解压识别。

我个人推荐路线一，因为打开pom.xml比打开文件夹更明确，IDEA会直接以Maven项目方式加载，不会出现“没识别成工程”的尴尬。

3.3 网页端和IDE内置向导怎么选

说句实在话，两者功能高度重合，但网页版有个隐藏加分项：它可以生成不带任何IDE依赖的纯基础工程。你下载下来的zip里没有任何IDEA特有的.idea目录，这意味着它可以被无差别导入到Eclipse、VS Code或者其他工具。如果你要在团队里推广统一模板，网页端生成后交给成员各自导入会更“干净”。

反过来，IDEA内置向导方便在生成的同时直接帮你创建好Gradle/Maven的本地配置，余下环节全自动，几乎不会操作失误。我的结论是：IDEA正常工作时就用内置向导，需要跨工具共享模板时用网页端，两手都备好。

4. 方式三：手动创建Maven工程，搞懂底层逻辑才是真懂了

会了前面两种方式，日常开发已经够用。但要是有人问你：“Maven项目是怎么变成Spring Boot项目的？”你如果说不知道，那基本功就露馅了。手动搭建一次Maven工程，能彻底打通你对Spring Boot构建链路的理解。

4.1 从空目录开始

打开IDEA，选择File → New → Project，这次左侧不选Spring Initializr，选最普通的Empty Project或者Maven Archetype（不勾选任何骨架），创建出一个空目录。

然后在空目录下手动创建以下目录结构：

myapp ├── pom.xml └── src ├── main │ ├── java │ └── resources └── test └── java

你可以用IDEA的右键菜单New → Directory一层层建，但更快的做法是直接在系统资源管理器里创建，再回到IDEA里右键选中目录，选择Mark Directory as → Sources Root和Resources Root，让IDEA识别源码目录的身份。

4.2 手写pom.xml

在项目根目录创建一个命名为pom.xml的文件，这是整个工程的灵魂。下面给一个最精简又能跑的版本，我用的是JDK 17对应的Spring Boot 3.x版本：

<?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>3.2.5</version> <relativePath/> </parent> <groupId>com.example</groupId> <artifactId>myapp</artifactId> <version>1.0.0</version> <properties> <java.version>17</java.version> </properties> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> </dependencies> <build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> </plugin> </plugins> </build> </project>

这里面的关键点有两个，我分别解释一下：

• spring-boot-starter-parent是Spring Boot提供的父POM，它统一管理了大量依赖的版本号。写上它，你在子依赖里就不用写每个jar包的version，它自动帮你顶到一个经过兼容性测试的版本组合。这就是Spring Boot“版本仲裁机制”的核心。
• spring-boot-maven-plugin这个插件负责把项目打成可执行Jar包，并同时支持mvn spring-boot:run直接启动。

拿到这段pom后，在IDEA右侧Maven工具栏点刷新，依赖会自动下载。

4.3 写主启动类并验证

在src/main/java下面建包，如果你的artifactId是myapp，可以建一个主包com.example.myapp，在里面新建类：

package com.example.myapp; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; @SpringBootApplication public class MyappApplication { public static void main(String[] args) { SpringApplication.run(MyappApplication.class, args); } }

然后右键运行main方法，只要看到控制台出现Spring Boot的启动日志和Tomcat端口信息，就说明这个纯手工工程已经完成了“普通Maven项目到Spring Boot项目”的蜕变。

注意：手动创建工程最容易犯的错误是包名层级和目录层级不对应。package com.example.myapp对应的目录必须是src/main/java/com/example/myapp，IDEA有时候会显示成平铺结构，但实际磁盘目录必须逐级对应，否则类能编译但扫描路径会出问题。

5. 方式四：Gradle路线，构建偏好不同但核心逻辑相通

如果你所在团队或者你长期接触的底层框架用的是Gradle，那第四种方式就必须会。Gradle的灵活性和脚本能力比Maven强，尤其在多模块项目和自定义任务方面更顺手。但就“创建Spring Boot项目”这个动作而言，过程几乎和方式三对称：写一个build.gradle，建好目录结构，写主类。

5.1 创建Gradle工程

IDEA里同样可以新建一个纯Gradle工程：File → New → Project，左侧选Gradle，不使用任何模板，建出基本工程结构。它的目录和Maven几乎一样，同样需要src/main/java和src/main/resources。

接着在根目录找到（或新建）build.gradle，写入下列内容：

plugins { id 'java' id 'org.springframework.boot' version '3.2.5' id 'io.spring.dependency-management' version '1.1.4' } group = 'com.example' version = '1.0.0' java { toolchain { languageVersion = JavaLanguageVersion.of(17) } } repositories { mavenCentral() } dependencies { implementation 'org.springframework.boot:spring-boot-starter-web' testImplementation 'org.springframework.boot:spring-boot-starter-test' }

这里的三个plugin声明把Gradle项目变成了Spring Boot项目。其中io.spring.dependency-management主要承担依赖版本统一管理功能，等价于Maven的父POM机制。

5.2 同步与启动

在IDEA右侧Gradle面板点击刷新，让插件下载并解析依赖。刷新完成后，创建和Maven方式相同的主启动类，照样用@SpringBootApplication注解启动。

这里有一个经验值得说说：首次用Gradle构建，下载依赖的速度往往比Maven慢，因为Gradle默认使用的仓库和Maven可选配置不同，还涉及Gradle自身发行包的下载。遇到卡顿别慌，换成国内镜像仓库后基本能解决。

5.3 Maven和Gradle怎么选

我个人观点很简单：两者能生成同样的运行结果，区别主要在团队技术栈、部署流水线以及个人习惯。Maven的XML格式繁琐但结构稳定，Gradle的DSL简洁但学习曲线陡一点。在创建项目这个环节，你只需要知道自己选的构建工具会在哪个文件里声明依赖即可。

如果你手头有现成的Maven Spring Boot项目，想通过Gradle重新构建，理论上也能写一个等价的build.gradle文件，再用IDEA的“Link Gradle Project”功能导入。但日常尽量别干这事，除非你有强烈的构建性能优化需求。

6. 方式五：Spring CLI命令行，脚本化与批量场景的利器

五种方式里，前面四种都离不开图形界面，第五种则是纯命令行操作：Spring CLI。接触过Spring生态的就懂，它背后是Spring Initializr的REST API，你用一长串参数就能在几秒内生成一个标准工程。

6.1 安装与初始化

安装CLI最省事的方式是用SDKMAN：

sdk install springboot

或者如果你用Homebrew，也可以直接装。安装完成后，在终端验证一下：

spring --version

只要输出版本号，环境就绪了。接着一条命令生成工程：

spring init --build=maven --java-version=17 --dependencies=web --group=com.example --artifact=cli-app cli-app

这条命令的执行结果会在当前目录下生成一个名为cli-app的Spring Boot工程。参数解读如下：

• --build=maven：指定构建工具。
• --java-version=17：指定Java版本。
• --dependencies=web：对应Spring Web starter。
• --group和--artifact：对应Maven坐标。

生成完用IDEA打开这个目录即可。

6.2 CLI方式的真实适用场景

别以为CLI只是用来炫技，它有几个实际优势：

1. 批量创建：假如你要一次性创建多个微服务基础工程，写个循环调用spring init就完事，比手工点界面快一个量级。
2. 版本固化：CLI命令可以写进公司内部脚本，统一JDK版本和依赖套餐，所有新项目出生即“规整”。
3. 无IDE环境：在纯Linux服务器上，没有图形界面也可以完成项目初始化，随后代码发回IDE开发。

当然它的短板也明显：无法可视化勾选依赖，得记住一堆参数名。好在这类参数并不难，查一次帮助命令就够了。

6.3 扩展：CLI还能干别的

spring init只是CLI的一个命令。CLI还内置了spring run，可以直接运行以.groovy或.java为后缀的Spring脚本文件，适合快速验证小功能；还有spring boot子命令，能帮助你生成依赖清单等。如果你是个喜欢把重复劳动脚本化的人，这个工具值得长期保留。

7. 创建完成后的高频故障与避坑心得

到这里，五种方式都讲完了。但光会创建不算完，我发现自己和周围同事在新建项目后，多少都遇到过几个重复出现的问题。我换成速查表形式分享一下，这种最直观：

现象	常见原因	解决思路
启动类报Process finished with exit code 1	JDK版本与POM声明不符，或者启动类包路径错	检查Project Structure里的SDK设置，核对<java.version>
依赖下载极慢或失败	网络问题或仓库地址不可用	换成国内镜像仓库，配置Mavensettings.xml或Gradle仓库URL
运行后提示端口被占用	上一次进程未退出，或其他服务占了8080	改application.yml中的server.port，或终端里jps查残留进程
生成的目录没有resources文件夹	某些手动创建流程漏建了	手动建目录后Mark as Resources Root
包名中带了横杠，类上@SpringBootApplication扫描不到	包命名不符合Java规范	重新命名包，去掉连线符，且注意目录层级同步

7.1 依赖版本不一致问题

Spring Boot的版本升级会比较激进，尤其是3.x以后，很多配置项和默认行为都变了。新手最常见的坑是：用新版Spring Boot模板，却套用旧版教程里的配置，结果启动时各种报错。处理这类问题的通用法子是：先看spring-boot-starter-parent里的版本号，再搜对应版本的官方文档或更新日志，别盲目改依赖版本。

7.2 网络环境带来的差异

国内访问官方生成器和Maven中央仓库时，速度不稳定是常态，这点在创建阶段就会直接影响体验。我的建议很简单：IDEA插件、网页端、CLI只要能联网都可能遇到这个问题，最后兜底手段是用“手动方式”创建工程并依赖本地仓库里已有的公共包，或者配置好镜像仓库再继续后续动作。

7.3 别做多余的操作

还有一条提醒：无论用哪种方式创建完项目，那些自动生成的测试类暂时不用删除，带着它们也不影响运行。有些同学一建好就手动清理.idea文件夹、删掉test目录，反而把默认配好的东西搞坏，得不偿失。

8. 最后说几句实在建议

文章写到这里，五条创建路线都给全了。如果非要我压缩成一条实操建议，我会这么安排：

• 日常业务开发：默认用方式一，IDEA内置向导足够好，别反复横跳。
• 需要分享模板或者换工具链：用方式二，让工程尽可能纯净。
• 想理解框架、准备面试或者手写精简工程：方式三走一遍。
• 团队构建体系偏向脚本化、多模块：方式四跟进团队的Gradle语法习惯。
• 自动化运维、批量生成、服务器上操作：方式五是最优解。

在带新人这件事上，我从来不强求第一次就用方式三去手撸pom.xml，但我会要求他们至少完整走一遍手动流程。因为“向导帮我们规避问题”和“我们亲自解决问题”带来的肌肉记忆是完全不同的。等你哪一天不用看任何教程，也能在五分钟内从一个空白目录徒手搭出一个能跑的Spring Boot工程，再回来看各种向导，那种感觉会是“哦，不过如此”，而不是“这会不会点错了”。

最后再补充一个小技巧：如果你手头已经有一个成熟的老项目，又不想每次创建新模块都重新走向导，可以把老项目里的pom.xml和主启动类复制一份，改掉artifactId和包名，再删掉业务代码，就能快速获得一个“带自家定制配置”的空白工程。这个土办法，我在赶工期的时候用过很多次，效率很高。希望这篇能帮你少走一点弯路，少踩几个坑。