用 IntelliJ IDEA 创建 Spring Boot 项目看起来是件小事但我在带新人的时候发现恰恰是这一步能把入门者分岔成两类一类顺利跑起了项目另一类卡在“怎么生成骨架”上大半天。严格说IDEA 里创建 Spring Boot 项目至少有五种路径它们背后对应的是不同的 IDEA 版本、不同的网络条件和不同的理解深度。这篇文章我把五条路全部摆出来每一步怎么操作、每条路有什么坑、分别适合谁都讲清楚你要是能把这五种方式都过一遍后面再遇到项目创建层面的问题基本不用求人。1. 创建方式多样化的根源IDEA版本分工与各自的适用场景1.1 社区版和旗舰版在Spring Boot支持上的本质区别很多人不理解为什么别人口中“IDEA里创建Spring Boot”的操作路径跟自己完全不一样核心原因其实是 IntelliJ IDEA 分成了两个发行线社区版Community和旗舰版Ultimate。旗舰版面向企业级开发内置了对 Spring 生态的完整支持所以你新建项目时可以直接看到 Spring Initializr 相关选项向导点几下项目就出来了。社区版是免费开源的版本本身定位是纯 Java 基础开发不捆绑 Spring 这类企业框架的脚手架服务所以默认情况下你找不到那个向导入口。这一点必须先讲清楚因为后面的几种创建方式本质上都是在回答同一个问题在缺少某个官方入口的情况下用什么替方案把 Spring Boot 项目“变”出来。理解了版本差异再去看各种教程里的操作路径就不会觉得乱了。1.2 五种创建方式的本质区别抛开具体的菜单路径五种方式的内核其实可以分成三类一类是“由工具生成骨架”。IDEA 内置 Spring Initializr 向导、Spring Assistant 插件、官网 start.spring.io 生成都属于这一类区别只在调用入口不同底层走的都是 Spring Initializr 的服务逻辑帮你把目录、pom、启动类、配置文件全部生成好。另一类是“由 Maven 模板生成骨架”。用 Maven 原型archetype创建项目走的是 Maven 的一套老机制它也会生成一个基础结构但和 Initializr 生成的内容不是一回事版本一般偏旧需要手动调整。第三类是“手动搭骨架”。从空 Maven 项目开始自己加依赖、自己写启动类、自己建 resources 目录。这种方式的效率最低但对项目结构的理解最深。选哪条路取决于你手头是哪个版本的 IDEA、你处在什么样的网络环境、以及你到底是想快速跑起来还是想彻底搞懂底层。下面我把五条路逐一展开。2. 方式一用IDEA内置Spring Initializr向导一键生成旗舰版最顺手的路径2.1 操作路径与关键字段说明如果你用的是旗舰版那么 File → New → Project在弹出的面板里找到 Spring Initializr部分较新版本的位置略有调整但一定在这个入口附近就可以进入 Spring Boot 项目的创建向导。这个向导本质上是在你的 IDEA 里内置了一个调用 Spring Initializr 服务的客户端。你需要填的东西有 Name、Language、Type、Group、Artifact、Package name、JDK 版本还有右侧的依赖选择区。先用最简配置跑通Language 选 JavaType 保持 Maven依赖里先选 Spring Web其他可以全不选。JDK 版本注意跟本地已安装的版本匹配比如本机是 JDK 17就选 17Spring Boot 版本一般用默认推荐的稳定版即可。填完这些点 FinishIDEA 就开始创建项目并下载 Maven 依赖。第一次等待时间会比较长右下角能看到依赖解析的进度条属于正常现象不用慌。2.2 网络异常的兜底方案换成镜像地址这条路径有一个很典型的坑Spring Initializr 的默认服务地址是官方站点如果你所在环境的网络对这个站点访问不稳定创建时会报错或者一直卡在拉取模板那一步项目根本生成不出来。解决办法是手动把 Server URL 换成本地网络能稳定访问的镜像地址。国内不少云厂商都维护了 Spring Initializr 的镜像服务地址格式一般形如 start.xxx.com你在向导页面找到 URL 那一栏把它换成可用的镜像地址就行。这里有一个需要留意的细节镜像上的 Spring Boot 可用版本列表不一定和官方完全同步可能略微滞后。如果你选择了较低的 Spring Boot 版本生成之后再手动把 pom.xml 里的版本号改成你需要的版本即可不太影响使用。2.3 生成后必做的三件事项目生成不算完能跑起来才算。第一件事是确认右侧 Maven 面板能正确识别项目如果 pom.xml 没有被加载项目图标上会有特殊标记此时右键 pom.xml → Add as Maven Project 即可。第二件事是找启动类。Initializr 生成的项目里src/main/java 的根包下会有一个带SpringBootApplication注解的启动类类名通常和 Artifact 相关运行它就能启动项目。第三件事是访问一下接口验证环境因为只选了 Spring Web默认是没有 Controller 的你可以先启动看日志看到 Tomcat started 就说明骨架没问题。想更彻底一点就在启动类所在包下新建一个简单的 Controller写一个返回字符串的接口再用浏览器访问一次这一轮创建才算真正闭环。3. 方式二社区版用Spring Assistant插件生成免费版也能走向导3.1 插件安装与注意事项社区版用户也不必只能眼巴巴看旗舰版用向导。IDEA 的插件市场里有一个叫 Spring Assistant 的插件属于社区开发者维护的第三方插件装上之后社区版的新建项目面板里也会出现类似 Spring Initializr 的入口。安装步骤很简单Settings → Plugins → Marketplace搜索 Spring Assistant确认后 Install然后重启 IDEA。重启后新建项目你会看到 Spring Assistant 或 Spring Initializr 的选项点进去之后的操作逻辑和旗舰版内置向导几乎一致同样需要填项目元信息、选依赖、选版本底层也是去请求 Initializr 服务。使用这个插件要有一个心理准备它不是官方出品版本的维护和兼容性不一定跟得上 IDEA 每两三个月的快速迭代。有时 IDEA 升级到某个大版本之后Spring Assistant 插件会失效或者入口消失这种情况并不少见我也遇到过不止一次。如果遇到不必死磕插件直接退回方式三官网生成再导入反而更省时间。3.2 插件失效后的退路插件失效后的退路其实也是社区版用户绕不开的通用方案去官网把项目生成好再导入 IDEA。这正好就是下面要讲的第三种方式。我的个人习惯是如果只是偶尔创建一个 Spring Boot 项目社区版根本不用装插件直接走官网生成如果是短时间要批量创建多个项目装 Spring Assistant 插件尝鲜一下还行但别指望它像官方内置功能那样稳定。反正项目本身是标准 Maven 工程谁生成的不重要最终进入 IDEA 的形态完全一样。4. 方式三Spring Initializr官网生成再导入IDEA适合团队协作与跨环境4.1 在网页上完成骨架配置打开 Spring Initializr 的网页版你会看到一个和 IDEA 内嵌向导长得几乎一样的表单这并不奇怪因为 IDEA 的内置向导本来就是在调用同一套服务。网页版的好处是所见即所得右侧能实时预览项目结构依赖可以多选几个试试等到自己要用的依赖不熟悉时可以一个一个加进去看生成结构适合学习。网页上需要填的字段和 IDEA 向导里基本一致ProjectMaven 或 Gradle、LanguageJava、Kotlin 或 Groovy、Spring Boot 版本、Group、Artifact、依赖。填好之后点 Generate 按钮网站就会打包下载一个 zip 压缩包里面就是完整的项目骨架。还有一点网页版生成项目后会给你一个“复制生成命令”的选项把参数拼成 curl 命令。这个功能很适合团队内部统一规范把命令固定下来以后谁要新项目直接复制命令跑一遍得到的就是结构完全一致的项目。4.2 导入IDEA及首次依赖下载加速拿到 zip 之后先解压到本地目录然后用 IDEA 的 File → Open选中这个文件夹IDEA 会自动识别里面的 pom.xml 并把它当作 Maven 工程加载进来。如果 IDEA 识别得比较迟钝也可以选 File → New → Project from Existing Sources然后手动指定 pom.xml效果一样。这个导入流程对社区版和旗舰版都适用所以我说它是“跨环境”的万能方式。唯一的痛点是首次打开项目时Maven 会把大量依赖从远端仓库拉到本地网速不行的话能卡很久。这种情况的常规解法是给 Maven 配置国内镜像仓库在用户目录下的.m2/settings.xml里添加镜像地址之后再刷新项目依赖下载速度会明显改善。4.3 为什么这种方式的“标准化价值”最明显如果只是一个人本地开发方式一和方式二其实体验更好因为不用离开 IDEA。但放到团队协作的场景方式三的优势立刻显现生成动作和 IDE 完全解耦不管团队里有人用 IDEA、有人用 Eclipse也不管谁用的是社区版还是旗舰版只要大家用同一份生成参数、同一个 Spring Boot 版本得到的项目结构就是一致的。我实际带项目时很看重这一点。新人入职给一份标准操作文档让所有人用官网生成同一依赖组合的项目而不是每个人在 IDEA 里自由发挥能省掉大量“你项目里怎么多个文件”“为什么你的依赖和我不同”的沟通成本。等到团队规模大了甚至可以基于这种方式自建一套内部生成服务把这一步再自动化。5. 方式四用Maven原型(archetype)创建Spring Boot项目命令行老兵的熟悉配方5.1 archetype的具体配置参数Maven 本身有一套基于原型的项目生成机制IDEA 作为 Maven 的图形化前端自然也能走这条路。操作入口是File → New → Project → Maven勾选 Create from archetype从原型创建然后点 Add Archetype 手动添加一个原型坐标。Spring Boot 官方其实提供过一个原型坐标大致是GroupIdorg.springframework.bootArtifactIdspring-boot-archetypeVersion选择一个可用的版本填完之后在原型列表里选中它继续填 GroupId、ArtifactId、Version、Package name 等常规信息IDEA 就会按照这个原型模板生成项目。这个方式最大的价值是它不依赖 Spring Initializr 服务不依赖特定的 IDE 版本只依赖 Maven 自身的原型仓库。如果你的工作环境是内网隔离的、没有外网访问 Initializr 服务的条件但本地有 Maven 私服缓存archetype 这条路径往往能正常走通。5.2 生成后必须处理的版本“历史遗留”说实话我用这种方式创建项目时踩过不少坑最典型的是原型版本滞后。Spring Boot 官方对这个 archetype 的维护频率并不高很多时候你能拉到的最新原型版本还是 2.x 时代。用旧原型生成的项目pom.xml 里带的 Spring Boot 版本、Java 版本、甚至部分依赖的命名方式都跟当前主流版本有差距。直接启动往往会出现编译失败或版本不兼容的报错你需要在生成的 pom 里手动把 Spring Boot 版本改成想用的版本同时把java.version调成和本机 JDK 一致。如果在 Spring Boot 3.x 下使用原帖生成的、默认依赖还是 javax 命名空间的代码比如自己写了 Servlet 相关的类还需要注意从javax.*到jakarta.*的包名迁移问题。所以我的建议是用 archetype 创建后先不要急着写业务代码先把 pom 梳理清楚确认依赖能拉下来、启动类能启动再往下走。5.3 什么情况才建议用这种方式考虑到这些附加成本我不会把 archetype 当作日常首选。它最适合两类人一类是老 Maven 用户对 Maven 原型机制本身很熟悉不想引入 Initializr 的服务依赖另一类是身处内网环境、访问不了外部 Initializr 服务、但又能拿到本地 Maven 仓库里原型模板的开发者。对新人的建议是了解一下即可至少知道 IDEA 里还有这么一条路不要把它当成必须掌握的首选技能。因为从本质上说archetype 生成的只是“项目的起点”真正适合现代 Spring Boot 开发的还是 Initializr 那套更完整的脚手架。6. 方式五从空Maven项目手搓Spring Boot骨架把原理彻底搞懂的一条路6.1 手动补全pom.xml的三层结构前面四种方式工具都帮我们把项目结构生成好了。但如果你想真正理解 Spring Boot 项目为什么会是长成那样我强烈建议你至少手动搭一次。操作入口很朴素File → New → Project → Maven不勾选任何 archetype直接生成一个空 Maven 项目。它只有一个基础到不能再基础的 pom.xml以及空的 src 目录。然后你需要手动往 pom 里加三块核心内容。第一块是父工程把 Spring Boot 的依赖版本管理引入进来这样后面的依赖声明就不用写版本号了。第二块是起步依赖比如spring-boot-starter-web。这类起步依赖是 Spring Boot 的精髓它把某一个功能领域需要用到的所有依赖打包成了一个整体你只要声明一个Tomcat、Jackson、Spring MVC 这些全都自动带入。第三块是构建插件spring-boot-maven-plugin少了它项目虽然能跑但无法被 Maven 打包成可执行的 jar。parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version3.2.5/version relativePath/ /parent dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency /dependencies build plugins plugin groupIdorg.springframework.boot/groupId artifactIdspring-boot-maven-plugin/artifactId /plugin /plugins /build如果你平时只靠向导创建项目可能永远不知道这些配置为什么要存在手动敲一遍 pom 之后很多问题就自然想通了。6.2 手写启动类和配置文件pom 配置完还得手动补两样东西启动类和配置文件。启动类需要放在 src/main/java 下并且放在一个基础包路径里类上标注SpringBootApplication注解。这个注解实际上是一个组合注解它把配置、组件扫描、自动配置三个核心能力合在了一起这是 Spring Boot 能“开箱即用”的根本原因。package com.example.demo; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; SpringBootApplication public class DemoApplication { public static void main(String[] args) { SpringApplication.run(DemoApplication.class, args); } }配置文件就更简单了。在 src/main/resources 下新建一个application.properties里面先写一行server.port8081也行什么都不写也能启动默认端口就是 8080。这一步虽然简单但如果你没有亲手创建过 resources 目录后面写配置时容易找不到文件位置手动跑一遍就记住了。这里有一个我见过无数次的新手问题Controller 建在了启动类所在包的“外面”结果访问接口总报 404。根本原因就在于SpringBootApplication默认只扫描它所在包及其子包包结构放错了自然扫描不到。这种问题在手动搭建时更容易暴露因为工具生成的项目默认就把启动类放在了根包而手动创建时有人会随手建个子包踩一次坑以后就长记性了。6.3 我为什么不推荐新手长期只用手搓方式先说明一下我很推崇手动搭建作为学习手段但不推崇作为日常效率手段。因为一个真正工业级的 Spring Boot 项目依赖可能有几十上百个结构远比这个复杂如果你每次都手搓既容易出错又不值当。更合理的思路是用方式一或方式三生成一个标准骨架然后用“手动搭建”时理解的原理去调整这个骨架。换句话说向导负责生成你负责理解向导帮你节省重复劳动你靠原理去掌握项目背后的组织逻辑。两条腿走路才是比较舒服的开发状态。7. 五种方式对比总结与我的实际选型建议7.1 横向对比表格最后把五种方式放在一起看选择逻辑就非常清晰了。创建方式依赖的IDE版本网络要求操作成本最佳场景IDEA内置Initializr向导旗舰版需要访问Initializr服务低日常个人开发Spring Assistant插件社区版需要访问Initializr服务低社区版临时用向导官网生成后导入任意版本需要访问Initializr服务中团队标准化、跨IDE协作Maven archetype任意版本依赖Maven仓库中高内网环境、老Maven用户手动搭建任意版本只需能下依赖高学习原理、理解结构从网络依赖程度来看五种方式里只有 archetype 和手动搭建对 Initializr 服务本身没有依赖这也是它们在内网环境依然能用的原因。但从生成效率来看没有任何方式能比 Initializr 更快因为服务端已经帮你想好了依赖的组合方式。7.2 不同群体的推荐组合如果你是刚入门的新人我的建议是先用方式三在官网生成一个项目感受一下标准的 Spring Boot 工程长什么样然后照着方式五手动搭一次把 pom、启动类、配置文件的来龙去脉理清楚日常开发再回到方式一或方式三用效率最高的方式干活。如果你是团队负责人或者技术小组长优先考虑方式三把生成参数和依赖组合固定成规范文档让所有成员统一使用这是掉进“每个人的项目结构都不一样”这个坑里最省事的办法。如果你只是社区版用户想快速跑一个项目又不想装插件方式三永远是最好用的路子。Spring Assistant 插件可以装了试试但要能接受它偶尔掉链子的现实。最后再分享一个我自己的习惯不管是哪种方式创建的项目生成之后第一件事永远是启动一次、访问一次、提交一次 Git。先把基础链路跑通再写业务比什么都强。因为创建方式本身只是起点项目能不能稳定地二次开发拼的还是你对 Spring Boot 底层这块骨头的熟悉程度。
用 IntelliJ IDEA 创建 Spring Boot 项目看起来是件小事但我在带新人的时候发现恰恰是这一步能把入门者分岔成两类一类顺利跑起了项目另一类卡在“怎么生成骨架”上大半天。严格说IDEA 里创建 Spring Boot 项目至少有五种路径它们背后对应的是不同的 IDEA 版本、不同的网络条件和不同的理解深度。这篇文章我把五条路全部摆出来每一步怎么操作、每条路有什么坑、分别适合谁都讲清楚你要是能把这五种方式都过一遍后面再遇到项目创建层面的问题基本不用求人。1. 创建方式多样化的根源IDEA版本分工与各自的适用场景1.1 社区版和旗舰版在Spring Boot支持上的本质区别很多人不理解为什么别人口中“IDEA里创建Spring Boot”的操作路径跟自己完全不一样核心原因其实是 IntelliJ IDEA 分成了两个发行线社区版Community和旗舰版Ultimate。旗舰版面向企业级开发内置了对 Spring 生态的完整支持所以你新建项目时可以直接看到 Spring Initializr 相关选项向导点几下项目就出来了。社区版是免费开源的版本本身定位是纯 Java 基础开发不捆绑 Spring 这类企业框架的脚手架服务所以默认情况下你找不到那个向导入口。这一点必须先讲清楚因为后面的几种创建方式本质上都是在回答同一个问题在缺少某个官方入口的情况下用什么替方案把 Spring Boot 项目“变”出来。理解了版本差异再去看各种教程里的操作路径就不会觉得乱了。1.2 五种创建方式的本质区别抛开具体的菜单路径五种方式的内核其实可以分成三类一类是“由工具生成骨架”。IDEA 内置 Spring Initializr 向导、Spring Assistant 插件、官网 start.spring.io 生成都属于这一类区别只在调用入口不同底层走的都是 Spring Initializr 的服务逻辑帮你把目录、pom、启动类、配置文件全部生成好。另一类是“由 Maven 模板生成骨架”。用 Maven 原型archetype创建项目走的是 Maven 的一套老机制它也会生成一个基础结构但和 Initializr 生成的内容不是一回事版本一般偏旧需要手动调整。第三类是“手动搭骨架”。从空 Maven 项目开始自己加依赖、自己写启动类、自己建 resources 目录。这种方式的效率最低但对项目结构的理解最深。选哪条路取决于你手头是哪个版本的 IDEA、你处在什么样的网络环境、以及你到底是想快速跑起来还是想彻底搞懂底层。下面我把五条路逐一展开。2. 方式一用IDEA内置Spring Initializr向导一键生成旗舰版最顺手的路径2.1 操作路径与关键字段说明如果你用的是旗舰版那么 File → New → Project在弹出的面板里找到 Spring Initializr部分较新版本的位置略有调整但一定在这个入口附近就可以进入 Spring Boot 项目的创建向导。这个向导本质上是在你的 IDEA 里内置了一个调用 Spring Initializr 服务的客户端。你需要填的东西有 Name、Language、Type、Group、Artifact、Package name、JDK 版本还有右侧的依赖选择区。先用最简配置跑通Language 选 JavaType 保持 Maven依赖里先选 Spring Web其他可以全不选。JDK 版本注意跟本地已安装的版本匹配比如本机是 JDK 17就选 17Spring Boot 版本一般用默认推荐的稳定版即可。填完这些点 FinishIDEA 就开始创建项目并下载 Maven 依赖。第一次等待时间会比较长右下角能看到依赖解析的进度条属于正常现象不用慌。2.2 网络异常的兜底方案换成镜像地址这条路径有一个很典型的坑Spring Initializr 的默认服务地址是官方站点如果你所在环境的网络对这个站点访问不稳定创建时会报错或者一直卡在拉取模板那一步项目根本生成不出来。解决办法是手动把 Server URL 换成本地网络能稳定访问的镜像地址。国内不少云厂商都维护了 Spring Initializr 的镜像服务地址格式一般形如 start.xxx.com你在向导页面找到 URL 那一栏把它换成可用的镜像地址就行。这里有一个需要留意的细节镜像上的 Spring Boot 可用版本列表不一定和官方完全同步可能略微滞后。如果你选择了较低的 Spring Boot 版本生成之后再手动把 pom.xml 里的版本号改成你需要的版本即可不太影响使用。2.3 生成后必做的三件事项目生成不算完能跑起来才算。第一件事是确认右侧 Maven 面板能正确识别项目如果 pom.xml 没有被加载项目图标上会有特殊标记此时右键 pom.xml → Add as Maven Project 即可。第二件事是找启动类。Initializr 生成的项目里src/main/java 的根包下会有一个带SpringBootApplication注解的启动类类名通常和 Artifact 相关运行它就能启动项目。第三件事是访问一下接口验证环境因为只选了 Spring Web默认是没有 Controller 的你可以先启动看日志看到 Tomcat started 就说明骨架没问题。想更彻底一点就在启动类所在包下新建一个简单的 Controller写一个返回字符串的接口再用浏览器访问一次这一轮创建才算真正闭环。3. 方式二社区版用Spring Assistant插件生成免费版也能走向导3.1 插件安装与注意事项社区版用户也不必只能眼巴巴看旗舰版用向导。IDEA 的插件市场里有一个叫 Spring Assistant 的插件属于社区开发者维护的第三方插件装上之后社区版的新建项目面板里也会出现类似 Spring Initializr 的入口。安装步骤很简单Settings → Plugins → Marketplace搜索 Spring Assistant确认后 Install然后重启 IDEA。重启后新建项目你会看到 Spring Assistant 或 Spring Initializr 的选项点进去之后的操作逻辑和旗舰版内置向导几乎一致同样需要填项目元信息、选依赖、选版本底层也是去请求 Initializr 服务。使用这个插件要有一个心理准备它不是官方出品版本的维护和兼容性不一定跟得上 IDEA 每两三个月的快速迭代。有时 IDEA 升级到某个大版本之后Spring Assistant 插件会失效或者入口消失这种情况并不少见我也遇到过不止一次。如果遇到不必死磕插件直接退回方式三官网生成再导入反而更省时间。3.2 插件失效后的退路插件失效后的退路其实也是社区版用户绕不开的通用方案去官网把项目生成好再导入 IDEA。这正好就是下面要讲的第三种方式。我的个人习惯是如果只是偶尔创建一个 Spring Boot 项目社区版根本不用装插件直接走官网生成如果是短时间要批量创建多个项目装 Spring Assistant 插件尝鲜一下还行但别指望它像官方内置功能那样稳定。反正项目本身是标准 Maven 工程谁生成的不重要最终进入 IDEA 的形态完全一样。4. 方式三Spring Initializr官网生成再导入IDEA适合团队协作与跨环境4.1 在网页上完成骨架配置打开 Spring Initializr 的网页版你会看到一个和 IDEA 内嵌向导长得几乎一样的表单这并不奇怪因为 IDEA 的内置向导本来就是在调用同一套服务。网页版的好处是所见即所得右侧能实时预览项目结构依赖可以多选几个试试等到自己要用的依赖不熟悉时可以一个一个加进去看生成结构适合学习。网页上需要填的字段和 IDEA 向导里基本一致ProjectMaven 或 Gradle、LanguageJava、Kotlin 或 Groovy、Spring Boot 版本、Group、Artifact、依赖。填好之后点 Generate 按钮网站就会打包下载一个 zip 压缩包里面就是完整的项目骨架。还有一点网页版生成项目后会给你一个“复制生成命令”的选项把参数拼成 curl 命令。这个功能很适合团队内部统一规范把命令固定下来以后谁要新项目直接复制命令跑一遍得到的就是结构完全一致的项目。4.2 导入IDEA及首次依赖下载加速拿到 zip 之后先解压到本地目录然后用 IDEA 的 File → Open选中这个文件夹IDEA 会自动识别里面的 pom.xml 并把它当作 Maven 工程加载进来。如果 IDEA 识别得比较迟钝也可以选 File → New → Project from Existing Sources然后手动指定 pom.xml效果一样。这个导入流程对社区版和旗舰版都适用所以我说它是“跨环境”的万能方式。唯一的痛点是首次打开项目时Maven 会把大量依赖从远端仓库拉到本地网速不行的话能卡很久。这种情况的常规解法是给 Maven 配置国内镜像仓库在用户目录下的.m2/settings.xml里添加镜像地址之后再刷新项目依赖下载速度会明显改善。4.3 为什么这种方式的“标准化价值”最明显如果只是一个人本地开发方式一和方式二其实体验更好因为不用离开 IDEA。但放到团队协作的场景方式三的优势立刻显现生成动作和 IDE 完全解耦不管团队里有人用 IDEA、有人用 Eclipse也不管谁用的是社区版还是旗舰版只要大家用同一份生成参数、同一个 Spring Boot 版本得到的项目结构就是一致的。我实际带项目时很看重这一点。新人入职给一份标准操作文档让所有人用官网生成同一依赖组合的项目而不是每个人在 IDEA 里自由发挥能省掉大量“你项目里怎么多个文件”“为什么你的依赖和我不同”的沟通成本。等到团队规模大了甚至可以基于这种方式自建一套内部生成服务把这一步再自动化。5. 方式四用Maven原型(archetype)创建Spring Boot项目命令行老兵的熟悉配方5.1 archetype的具体配置参数Maven 本身有一套基于原型的项目生成机制IDEA 作为 Maven 的图形化前端自然也能走这条路。操作入口是File → New → Project → Maven勾选 Create from archetype从原型创建然后点 Add Archetype 手动添加一个原型坐标。Spring Boot 官方其实提供过一个原型坐标大致是GroupIdorg.springframework.bootArtifactIdspring-boot-archetypeVersion选择一个可用的版本填完之后在原型列表里选中它继续填 GroupId、ArtifactId、Version、Package name 等常规信息IDEA 就会按照这个原型模板生成项目。这个方式最大的价值是它不依赖 Spring Initializr 服务不依赖特定的 IDE 版本只依赖 Maven 自身的原型仓库。如果你的工作环境是内网隔离的、没有外网访问 Initializr 服务的条件但本地有 Maven 私服缓存archetype 这条路径往往能正常走通。5.2 生成后必须处理的版本“历史遗留”说实话我用这种方式创建项目时踩过不少坑最典型的是原型版本滞后。Spring Boot 官方对这个 archetype 的维护频率并不高很多时候你能拉到的最新原型版本还是 2.x 时代。用旧原型生成的项目pom.xml 里带的 Spring Boot 版本、Java 版本、甚至部分依赖的命名方式都跟当前主流版本有差距。直接启动往往会出现编译失败或版本不兼容的报错你需要在生成的 pom 里手动把 Spring Boot 版本改成想用的版本同时把java.version调成和本机 JDK 一致。如果在 Spring Boot 3.x 下使用原帖生成的、默认依赖还是 javax 命名空间的代码比如自己写了 Servlet 相关的类还需要注意从javax.*到jakarta.*的包名迁移问题。所以我的建议是用 archetype 创建后先不要急着写业务代码先把 pom 梳理清楚确认依赖能拉下来、启动类能启动再往下走。5.3 什么情况才建议用这种方式考虑到这些附加成本我不会把 archetype 当作日常首选。它最适合两类人一类是老 Maven 用户对 Maven 原型机制本身很熟悉不想引入 Initializr 的服务依赖另一类是身处内网环境、访问不了外部 Initializr 服务、但又能拿到本地 Maven 仓库里原型模板的开发者。对新人的建议是了解一下即可至少知道 IDEA 里还有这么一条路不要把它当成必须掌握的首选技能。因为从本质上说archetype 生成的只是“项目的起点”真正适合现代 Spring Boot 开发的还是 Initializr 那套更完整的脚手架。6. 方式五从空Maven项目手搓Spring Boot骨架把原理彻底搞懂的一条路6.1 手动补全pom.xml的三层结构前面四种方式工具都帮我们把项目结构生成好了。但如果你想真正理解 Spring Boot 项目为什么会是长成那样我强烈建议你至少手动搭一次。操作入口很朴素File → New → Project → Maven不勾选任何 archetype直接生成一个空 Maven 项目。它只有一个基础到不能再基础的 pom.xml以及空的 src 目录。然后你需要手动往 pom 里加三块核心内容。第一块是父工程把 Spring Boot 的依赖版本管理引入进来这样后面的依赖声明就不用写版本号了。第二块是起步依赖比如spring-boot-starter-web。这类起步依赖是 Spring Boot 的精髓它把某一个功能领域需要用到的所有依赖打包成了一个整体你只要声明一个Tomcat、Jackson、Spring MVC 这些全都自动带入。第三块是构建插件spring-boot-maven-plugin少了它项目虽然能跑但无法被 Maven 打包成可执行的 jar。parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version3.2.5/version relativePath/ /parent dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency /dependencies build plugins plugin groupIdorg.springframework.boot/groupId artifactIdspring-boot-maven-plugin/artifactId /plugin /plugins /build如果你平时只靠向导创建项目可能永远不知道这些配置为什么要存在手动敲一遍 pom 之后很多问题就自然想通了。6.2 手写启动类和配置文件pom 配置完还得手动补两样东西启动类和配置文件。启动类需要放在 src/main/java 下并且放在一个基础包路径里类上标注SpringBootApplication注解。这个注解实际上是一个组合注解它把配置、组件扫描、自动配置三个核心能力合在了一起这是 Spring Boot 能“开箱即用”的根本原因。package com.example.demo; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; SpringBootApplication public class DemoApplication { public static void main(String[] args) { SpringApplication.run(DemoApplication.class, args); } }配置文件就更简单了。在 src/main/resources 下新建一个application.properties里面先写一行server.port8081也行什么都不写也能启动默认端口就是 8080。这一步虽然简单但如果你没有亲手创建过 resources 目录后面写配置时容易找不到文件位置手动跑一遍就记住了。这里有一个我见过无数次的新手问题Controller 建在了启动类所在包的“外面”结果访问接口总报 404。根本原因就在于SpringBootApplication默认只扫描它所在包及其子包包结构放错了自然扫描不到。这种问题在手动搭建时更容易暴露因为工具生成的项目默认就把启动类放在了根包而手动创建时有人会随手建个子包踩一次坑以后就长记性了。6.3 我为什么不推荐新手长期只用手搓方式先说明一下我很推崇手动搭建作为学习手段但不推崇作为日常效率手段。因为一个真正工业级的 Spring Boot 项目依赖可能有几十上百个结构远比这个复杂如果你每次都手搓既容易出错又不值当。更合理的思路是用方式一或方式三生成一个标准骨架然后用“手动搭建”时理解的原理去调整这个骨架。换句话说向导负责生成你负责理解向导帮你节省重复劳动你靠原理去掌握项目背后的组织逻辑。两条腿走路才是比较舒服的开发状态。7. 五种方式对比总结与我的实际选型建议7.1 横向对比表格最后把五种方式放在一起看选择逻辑就非常清晰了。创建方式依赖的IDE版本网络要求操作成本最佳场景IDEA内置Initializr向导旗舰版需要访问Initializr服务低日常个人开发Spring Assistant插件社区版需要访问Initializr服务低社区版临时用向导官网生成后导入任意版本需要访问Initializr服务中团队标准化、跨IDE协作Maven archetype任意版本依赖Maven仓库中高内网环境、老Maven用户手动搭建任意版本只需能下依赖高学习原理、理解结构从网络依赖程度来看五种方式里只有 archetype 和手动搭建对 Initializr 服务本身没有依赖这也是它们在内网环境依然能用的原因。但从生成效率来看没有任何方式能比 Initializr 更快因为服务端已经帮你想好了依赖的组合方式。7.2 不同群体的推荐组合如果你是刚入门的新人我的建议是先用方式三在官网生成一个项目感受一下标准的 Spring Boot 工程长什么样然后照着方式五手动搭一次把 pom、启动类、配置文件的来龙去脉理清楚日常开发再回到方式一或方式三用效率最高的方式干活。如果你是团队负责人或者技术小组长优先考虑方式三把生成参数和依赖组合固定成规范文档让所有成员统一使用这是掉进“每个人的项目结构都不一样”这个坑里最省事的办法。如果你只是社区版用户想快速跑一个项目又不想装插件方式三永远是最好用的路子。Spring Assistant 插件可以装了试试但要能接受它偶尔掉链子的现实。最后再分享一个我自己的习惯不管是哪种方式创建的项目生成之后第一件事永远是启动一次、访问一次、提交一次 Git。先把基础链路跑通再写业务比什么都强。因为创建方式本身只是起点项目能不能稳定地二次开发拼的还是你对 Spring Boot 底层这块骨头的熟悉程度。
