SpringBoot项目创建的5种方式与避坑指南

前两天帮人排查一个启动失败的问题报错信息是“无效的源发行版17”折腾了半天最后发现根子就出在项目创建这一步——他用IDEA的Spring Initializr向导选了Spring Boot 3.x本机JDK却还停在8。这不是我第一次遇到有人卡在“创建SpringBoot项目”这个看起来很简单的操作上了。说句实在话用IDEA创建SpringBoot项目这件事远没有表面上那么“Next Next Next”就完事。内置向导、网页生成器、镜像源、手动搭建、复制改造我前后梳理下来能落地的至少有五种方式而且每一种都有自己不可替代的使用场景也都有对应的坑。这篇文章我就把这五种方式挨个拆一遍每种方式讲清楚适合谁、怎么做、会踩什么坑顺便把创建之后那些十个人里九个会遇到的启动问题也一起处理掉。1. 五种方式的对号入座场景不同选择完全不同1.1 为什么创建SpringBoot项目会有这么多种方式很多人不理解为什么创建个SpringBoot项目还要分这么多种方式直接向导下一步下一步不就完了吗这里的关键在于SpringBoot项目本质上不是什么特殊的东西它就是一个基于Maven或者Gradle的标准工程结构加上特定的起步依赖再靠自动装配机制把各个组件拉起来。所以任何能生成标准Maven目录结构、能正确配置依赖、能让你写出一个启动类的东西都可以作为SpringBoot项目的创建方式。另一个现实因素是大家手里的IDEA版本不一样。有的用Ultimate版内置Spring Initializr用得飞起有的用Community版打开New Project连Spring Initializr的影子都看不到。还有的是公司内网环境访问不了官方的工程生成服务只能靠镜像源或者完全离线手动搭。这些现实差异导致“创建SpringBoot项目”这个问题有了多种解法且每种解法都有它存在的道理。1.2 五种方式横向对比直接对号入座我把这五种方式涉及的载体、联网要求、IDEA版本要求和适用人群做了个对比你看了直接对号入座。创建方式核心载体是否必须联网IDEA版本要求适用场景IDEA内置Spring InitializrIDEA向导需要可切换源Ultimate版新老版本都支持大部分日常开发标准流程start.spring.io网页生成浏览器需要任意版本社区版也能用IDEA社区版、需要离线传输工程包阿里云镜像InitializrIDEA向导或网页需要任意版本官方源访问慢、内网受限Maven空工程手动搭建IDEA Maven可完全离线任意版本适合理解原理、排查依赖问题复制已有项目改造本地文件可完全离线任意版本企业脚手架复用、老项目迁移从推荐度来看如果你用的是Ultimate版且网络正常无脑用方式一没问题如果你是社区版用户方式二就是你的救命稻草如果你想真正搞懂SpringBoot的自动装配和依赖传递方式四值得你完整走一遍。至于方式五那是企业开发里隐藏的高频操作很多人的新项目不是“创建”出来的而是“复制改造”出来的。2. 方式一IDEA内置向导官方源生成项目的常规路径2.1 新版IDEA里的向导入口和配置项用IDEA自带向导创建SpringBoot项目不同版本的界面差别还挺大。老版本IDEA的操作路径是File - New - Project左侧直接能看到Spring Initializr然后右侧填Group、Artifact选Spring Boot版本勾选所需依赖最后点Finish就生成完事。新版IDEA2020.3以后的界面变成了File - New - Project在左侧的Generators列表里找Spring Boot或者Spring Initializr这一项。如果你用的是更早一点的版本可能入口在Spring Assistant插件里不过整体逻辑都是一样的填工程坐标 - 选构建工具 - 选Spring Boot版本 - 选依赖 - 生成工程。填配置的时候有几个点需要特别留意。Project SDK那一栏一定要选到本机实际安装的JDK目录不要停留在IDEA自带的那个JRE选项上。很多人在这里随手选了个默认值后面启动项目直接报“无效的源发行版”排查半天才发现是SDK选错了。然后是Spring Boot版本的选择。这里我必须多啰嗦一句Spring Boot 2.x系列要求Java 8或以上但Spring Boot 3.x强制要求Java 17及以上。如果你的环境还停留在JDK 8切记要把版本切换到2.7系列否则项目建出来就是一堆编译错误。热搜词里那个“springboot版本太高”指的就是这种情况。2.2 生成的工程目录到底在说什么通过向导生成的项目默认目录结构长这样demo ├── pom.xml ├── src │ ├── main │ │ ├── java │ │ │ └── com/example/demo │ │ │ └── DemoApplication.java │ │ └── resources │ │ ├── application.properties │ │ └── static / templates按需生成 │ └── test │ └── java │ └── com/example/demo │ └── DemoApplicationTests.javaDemoApplication这个类是整个项目的入口它的代码非常简单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); } }很多人想不明白为什么一个带main方法的类就能直接启动一个Web服务这背后全靠SpringBootApplication这个组合注解。2.3 自动装配是怎么“自动”起来的既然热词里出现了“springboot自动装配原理”这里就用大白话把机制说透。SpringBootApplication实际上由三个注解组合而成SpringBootConfiguration、EnableAutoConfiguration、ComponentScan。EnableAutoConfiguration是核心。它做的事情是去读取Spring Boot自动装配配置文件里注册的所有自动配置类。在Spring Boot 2.x里这个文件位于META-INF/spring.factories在Spring Boot 3.x里改成了META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports。自动配置类密密麻麻一大堆比如DataSourceAutoConfiguration、RedisAutoConfiguration、ServletWebServerFactoryAutoConfiguration。如果全部生效那得启动多少无用的Bean所以每个自动配置类里基本都有ConditionalOnClass、ConditionalOnProperty、ConditionalOnMissingBean这些条件注解。翻译成人话就是你导入了某个starter依赖类路径上有了对应的类这个自动配置才生效你在配置文件里写了对应属性配置才会被绑定。这也是为什么在SpringBoot里集成Redis、ActiveMQ、RocketMQ会变得极其简单——你只要加一个starter然后写几行配置自动装配帮你把剩下的活全干了。理解了这套机制你也就理解了为什么说SpringBoot是“约定优于配置”。3. 方式二start.spring.io网页生成社区版用户的正解3.1 网页端生成流程30秒拿到工程包IDEA社区版是免费的但代价就是没有内置的Spring Initializr向导。这不代表社区版用户就没法优雅地创建SpringBoot项目官方把同样的向导能力做成了网页版。直接打开 start.spring.io 这个页面就是可视化的工程生成器。你需要选择的项其实和IDEA向导完全一样Project选Maven还是Gradle绝大多数人用MavenLanguageJava、Kotlin、Groovy三选一默认JavaSpring Boot版本系统会给你一个默认版本注意看它要求的JDK版本Group一般是公司域名反写比如com.exampleArtifact项目名Dependencies右侧输入框里搜依赖比如web、security、data-redis点一下Add就行依赖选完之后页面右下角点Generate浏览器就会下载一个zip压缩包。整个过程30秒都用不了。这里有一个细节网页端默认给的Spring Boot版本可能很高如果你的环境是JDK 8记得在页面左上角的Spring Boot版本下拉框里手动切到2.7系列再点生成。3.2 导入IDEA最稳妥的方式网页端下载的是zip包导入IDEA的方式有讲究方式不对容易把工程结构搞乱。先把zip解压到一个干净目录目录名最好是英文且和Artifact保持一致。然后打开IDEA选择File - New - Project from Existing Sources定位到解压后的目录选择pom.xml文件以Maven项目的方式导入。IDEA会识别出这是一个Maven工程然后开始下载依赖。还有一种方式是File - Open直接打开解压后的文件夹IDEA会自动检测到里面的pom.xml并导入。这两个方式都可以但方式一更稳妥一些能确保你是以Maven工程来加载。导入完成后右下角会提示“Maven projects need to be imported”点Enable Auto-Import让依赖变化时自动刷新。第一次导入时Maven会下载大量依赖耗时长短取决于你的网络和Maven仓库配置。3.3 “SpringBoot版本太高”到底怎么处理网页端生成项目遇到版本太高的报错约等于每个SpringBoot新手都经历过的一劫。最典型的场景是用start.spring.io生成了Spring Boot 3.x的项目本地JDK是8一启动就报“java: 无法访问org.springframework.boot.SpringApplication / 错误的类文件版本”之类的错误根本原因就是类编译版本超出了JDK 8的识别范围。处理办法有两个方向。第一降版本。把pom.xml里的parent版本从3.x改到2.7.18parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.7.18/version relativePath/ /parent改完后点一下Maven窗口里的刷新图标让依赖重新解析。第二升JDK。如果你非要使用Spring Boot 3.x那就老老实实把本机JDK升级到17同时把IDEA里Project Structure的Project SDK和Modules的Language level全部切到17。这里顺带提一句如果你以后打算从Spring Boot 2.x升级到3.x不只是版本号变一下的事情包名从javax.迁移到了jakarta.很多第三方库的兼容性也要重新验证。所以版本选择这件事一开始就要想清楚。4. 方式三镜像源初始化网速与版本之间的必修平衡课4.1 把Server URL改成镜像源用IDEA内置向导时在配置界面的右上角有一个Server URL默认值是https://start.spring.io。这个URL就是你的SpringBoot工程模板和依赖清单的来源地址。因为官方服务器在境外有些网络环境下访问非常慢或者直接超时导致向导卡在“Connection timed out”那一步。解决办法是把Server URL替换成国内可用的镜像源。比较常见的是阿里云提供的https://start.aliyun.com在IDEA内置向导里把这个URL替换进去再点右侧的刷新按钮。准备好之后依赖列表和版本列表都会从镜像源重新加载创建速度会有质的提升。如果你的IDEA版本界面里没有Server URL这个输入框也别慌。看界面上是否有“Spring”相关的下拉选项或者在Advanced Settings里找一般都能找到。4.2 镜像源的版本筛选逻辑用阿里云镜像有一个必须说清楚的限制它的服务主要面向Spring Boot 2.x时代生成的模块版本整体偏旧。你可能会发现镜像源里提供的Spring Boot版本最高就到2.7系列找不到3.x。这是正常的不是配置错了。镜像源维护的元数据和官方源是不同步的尤其对于新版本的收录有明显的滞后。所以我的建议是如果只是想在内网环境快速生成一个Spring Boot 2.x的项目用阿里云镜像非常舒服如果你必须要用Spring Boot 3.x那就用官方源生成之后再手动修改pom.xml里的版本号如果你发现镜像源生成的工程连pom.xml都是旧的那就对标官方工程结构手动改依赖坐标说到底镜像源解决的问题是“网络能不能通”和“下载快不快”至于版本新旧的选择还是把握在你自己手里。4.3 Maven依赖仓库也要走镜像否则白搭这一点特别容易踩坑。不少人在IDEA内置向导里把Server URL改成了阿里云镜像创建项目倒是飞快。但项目建好后Maven开始下载依赖时又卡住不动了或者反复报超时。原因很简单Server URL解决的是“工程模板从哪儿来”而Maven依赖下载解决的是“jar包从哪个仓库拉”这是两套完全独立的路径。SpringBoot的依赖包默认是去Maven中央仓库下载的中央仓库在境外照样慢。正确的处理方式是在Maven的settings.xml里配置阿里云镜像仓库。找到你的Maven安装目录下的conf/settings.xml或者用户目录下.m2/settings.xml在mirrors节点里加上mirror idaliyunmaven/id mirrorOfcentral/mirrorOf name阿里云公共仓库/name urlhttps://maven.aliyun.com/repository/public/url /mirror配置完之后在IDEA的Settings - Build, Execution, Deployment - Build Tools - Maven里把User settings file指向这个settings.xml文件点Apply再点刷新。这样依赖下载才会真正走国内镜像。我见过太多人只改Server URL不配Maven镜像最后跑了半天还是超时急得团团转。这两件事是配套的都得处理。5. 方式四Maven空工程手动搭建顺着SpringBoot原理走一遍5.1 创建一个空的Maven工程前面三种方式都是靠向导生成属于“站在巨人肩膀上”的做法。但如果你想搞清楚SpringBoot项目到底是怎么构成的强烈建议手动搭一次。整个过程不算难收获却非常大。第一步在IDEA里用Maven骨架创建一个空白工程。File - New - Project - Maven这里不需要选任何archetype模板默认就是一个只有pom.xml和src/main/java的空工程。如果你勾了网上教程常说的maven-archetype-quickstart也没问题只是会多出来一些示例代码。手动搭建时我习惯不选模板从零开始干净利落。5.2 手动补全pom.xml的完整配置空工程建好后pom.xml的配置完全靠手动写。核心配置文件长这样?xml version1.0 encodingUTF-8? project xmlnshttp://maven.apache.org/POM/4.0.0 xmlns:xsihttp://www.w3.org/2001/XMLSchema-instance xsi:schemaLocationhttp://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd modelVersion4.0.0/modelVersion parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.7.18/version relativePath/ /parent groupIdcom.example/groupId artifactIdmanual-demo/artifactId version0.0.1-SNAPSHOT/version properties java.version1.8/java.version /properties 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 /project这段配置里有三样东西值得你仔细理解。第一是spring-boot-starter-parent。它本身不实现业务功能但它是一个父POM帮我们把所有SpringBoot生态的依赖版本统一管理好了。你在依赖里不需要写spring-web的版本号因为父POM里的dependencyManagement已经把这些版本全部锁定了。这就是为什么SpringBoot项目的依赖很少出现版本冲突。第二是spring-boot-starter-web。这是起步依赖它通过Maven的依赖传递把spring-web、spring-webmvc、内嵌Tomcat等一堆依赖全部带入工程。一个依赖解决所有Web开发所需组件这就是“starter”机制的设计思路。第三是spring-boot-maven-plugin。没有它你也能启动项目但你会发现mvn package打出来的jar包根本不能直接运行。原因在于普通的jar不包含SpringBoot的启动逻辑ClassPath里也找不到依赖的jar。这个插件会执行repackage操作把工程repackage成可执行jar。5.3 写一个能跑的启动类和接口pom配置好之后在src/main/java/com/example/manualdemo目录下创建启动类package com.example.manualdemo; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; SpringBootApplication public class ManualDemoApplication { public static void main(String[] args) { SpringApplication.run(ManualDemoApplication.class, args); } }启动类的作用已经讲过这里不再重复。接下来在同一个包下建一个测试接口package com.example.manualdemo; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.RestController; RestController public class HelloController { GetMapping(/hello) public String hello() { return Hello, Spring Boot!; } }然后在src/main/resources目录下创建application.properties文件server.port8080 spring.application.namemanual-demo直接运行ManualDemoApplication的main方法等到控制台打印出Tomcat started on port(s): 8080再用浏览器访问http://localhost:8080/hello看到那句“Hello, Spring Boot!”这个手动搭建的项目就算完整跑通了。5.4 为什么我强烈建议你手动搭一次手动搭建的意义不在于省不省那几秒钟而在于它会逼着你把SpringBoot项目的构成元素全部过一遍起步依赖是怎么传递的、父POM管理了什么、SpringBootApplication为什么能启动Web服务、maven插件打包后做了什么。你以后排查问题时会发现很多难缠的报错最终都能归因到pom.xml上。依赖没有生效看看starter是否引入版本冲突看看传递依赖从哪里来包打出来不能运行看看spring-boot-maven-plugin有没有配。如果连工程结构是怎么组成的都不清楚排查问题就会像无头苍蝇一样乱撞。顺带说一句很多“SpringMVC工程改造成SpringBoot工程”的问题本质上也是这一套思路。老的Web项目里SpringMVC需要大量XML配置、需要部署到外部Tomcat改造为SpringBoot后这些工作都被起步依赖和自动装配替代了你要做的就是在原来代码的基础上补齐这样一个pom和入口类然后删掉冗余的XML配置即可。原理和手动搭建其实是相通的。6. 方式五复制已有项目改造企业开发里的高频操作6.1 复制、清理、重命名一套流程在企业开发中新项目的创建很多时候不是从零开始的而是基于公司内部的脚手架工程或者某个老项目复制改造的。原因也很简单公司的公共组件、日志规范、统一返回体、异常处理、代码格式化配置这些东西从头搭建一遍成本太高复制一个现成工程再改改效率是最高的。复制改造的完整流程大概是这样的。第一步在文件系统里复制整个项目文件夹然后改个新项目名比如把base-service改成order-service。第二步打开新目录删掉.idea文件夹、所有*.iml文件、target目录。这些是IDEA和Maven的编译产物和本地配置留着会导致新环境打开时出现各种奇奇怪怪的状态。第三步用IDEA以Maven项目的方式打开这个新目录。打开后先改pom.xml里的artifactId和name视情况也要改groupId。第四步如果你的新项目要换包名右键根包 - Refactor - RenameIDEA会帮你把整个代码里的包引用一并替换掉。这一步必须彻底做干净包括测试类里的包名。第五步修改配置文件。application.yml里的spring.application.name要改端口如果有冲突要改数据库连接、Redis地址、私服地址等都要换成新环境对应的配置。第六步全局搜索一下旧项目名的关键词把代码里的项目名、日志路径、注释里的项目代号全部清理干净。6.2 残留问题排查清单复制改造最折磨人的就是那些“看起来删干净了但还在”的残留问题。我列一个排查清单你照着逐一检查启动类扫描不到Controller检查启动类所在的包是否在顶层SpringBootApplication默认扫描当前包及子包如果Controller放错包路径会导致404端口冲突报“Web server failed to start. Port 8080 was already in use”用netstat -ano查端口占用或者直接改server.port数据库连接指向旧库把项目跑起来查到的是旧库的数据看配置文件的spring.datasource.url有没有改干净依赖和功能不匹配复制过来的项目可能带了用不上的强依赖比如Kafka、Elasticsearch新环境没有这些中间件就会启动失败按需删掉多余依赖日志路径残留日志文件写到旧目录下排查的时候找不到日志全局搜索旧路径改掉还有一个容易忽略的点复制项目后Maven的lastUpdated缓存可能导致新项目使用旧依赖解析结果。遇到诡异问题建议先执行mvn clean再在IDEA里File - Invalidate Caches做一次彻底清理。6.3 顺手聊聊SpringMVC工程怎样改成SpringBoot热搜词里有一句话是“springmvc工程如何改造成springboot工程”这个需求和复制改造项目的关系非常紧密。老SpringMVC工程的代码本身是可以继续用的关键是去掉旧的Spring配置方式。改造的核心是把XML配置换成JavaConfig和SpringBoot的自动装配。具体来说原SpringMVC工程里的web.xml尤其DispatcherServlet的配置SpringBoot里完全不需要了因为spring-boot-starter-web会自动配置DispatcherServlet。原来在spring-mvc.xml里写的注解扫描、视图解析器、静态资源映射SpringBoot通过自动配置和默认约定来处理。如果你有自定义的拦截器或过滤器用WebFilter ServletComponentScan或者通过WebMvcConfigurer注册Interceptor。整个改造过程本质上就是我前面说的方法四的手动方式只是代码量更大、涉及面更广。先把SpringBoot的pom和入口类搞定再逐步把XML配置迁移成类配置或直接删掉最后跑起来验证一遍。这个顺序能保证你每一步都有清晰的验证点不至于一次性改动太多出问题了都找不到方向。7. 项目落地后避不开的几个坑7.1 JDK版本不一致导致的启动失败“无效的源发行版17”这个报错在我帮人排查SpringBoot问题时出现的频率极高。它一共涉及四处JDK配置任何一处不一致都会触发。第一处是Project Structure里的Project SDK设置为实际安装的JDK版本。第二处是Modules里的Language level它决定编译器按哪个Java语法级别来编译。第三处是Settings - Build, Execution, Deployment - Build Tools - Maven - Runner里的JRE设置Maven执行编译时用的JDK以这里的配置为准。第四处是系统环境变量的JAVA_HOME某些命令行脚本会读取它。理想情况是这四处严格统一。比如你装的是JDK 8那么Project SDK选1.8Language level选8Runner里的JRE也选JDK 8JAVA_HOME指向JDK 8安装目录。你可能会遇到这样的情况Project SDK明明已经改了1.8但编译还是报错这时候十有八九是Runner那一栏没改。Maven的编译进程走的不是Project SDK而是它单独指定的JRE。我每次都会在最后检查一下这一项基本上都能命中问题。7.2 内嵌Tomcat的替换与WebServer选择SpringBoot默认内嵌的Web容器是Tomcat这也是它无需独立安装Tomcat就能跑起Web服务的原因。但有些项目出于性能或合规要求会想把内嵌Tomcat换掉。SpringBoot支持把Web容器替换为Undertow或Jetty。这个替换在SpringBoot里做起来异常简单因为所有Web容器都实现了同样的接口由自动装配来统一加载。替换为Undertow的配置方式dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId exclusions exclusion groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-tomcat/artifactId /exclusion /exclusions /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-undertow/artifactId /dependency首先要排除spring-boot-starter-web里默认带入的tomcat再添加undertow的starter这样自动装配就会检测到Undertow的类路径并启用它。热搜词里出现的“宝兰德替换tomcat”也是类似的思路把WebServer层替换成国产中间件本质上就是走这套排除与引入的路线。这种替换说起来简单但要额外评估一些边缘行为不同容器的Session机制、并发模型下的表现、部署时的兼容性。如果只是跟着教程配了一遍却不知道这些差异后面上线踩坑就来不及了。7.3 配置文件里最常用的几项SpringBoot支持application.properties和application.yml两种格式。个人更推荐yml结构清晰缩进一眼就能看清层级关系。一个常见的yml配置示例server: port: 8081 servlet: context-path: /api spring: application: name: order-service datasource: url: jdbc:mysql://localhost:3306/order_db?useUnicodetruecharacterEncodingutf8 username: root password: 123456context-path这一项经常被人忽略。配置了它之后所有接口的访问路径都会加上一个统一前缀比如上面配置了对/api原本访问/hello的接口就变成了/api/hello。另外还有一个很实用的小功能banner生成器。SpringBoot启动时控制台会打印一个ASCII艺术的banner网上有专门的banner生成网站可以把自己的项目名、团队名做成字符画写入src/main/resources/banner.txt里。虽然装饰性大于实用性但在团队文化上还是能整出点名堂的很多人喜欢玩这个。7.4 热部署、打包这类“后处理”内容开发阶段每次改代码都要重启服务是很影响效率的这时候可以给项目加入热部署支持。在pom.xml里添加devtools依赖dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-devtools/artifactId optionaltrue/optional /dependency加了依赖之后还需要在IDEA的Settings - Build, Execution, Deployment - Compiler里勾选Build project automatically同时按CtrlShiftA打开Registry勾选automake.allow.when.app.running。两步配合IDE才能在运行期间自动编译devtools检测到类变化后触发应用重启。打包时要注意最常用的命令是mvn clean package -DskipTests执行完在target目录下会生成一个xxx.jar通过java -jar xxx.jar就能运行。如果你用docker交付可以借助IDEA的Docker插件或者写Dockerfile把打好的jar打进镜像里。这种打包镜像的操作在热搜词里也有实际项目里基本都会用到。还有一个细节使用spring-boot-maven-plugin打包后的jar分为两类一类是可执行的SpringBoot fat jar一类是普通jar。如果你把jar包给其他模块作为依赖引用需要额外配置classifier。这个坑相对冷门但遇到的时候非常困扰在此提一句以避免有人踩坑。写在最后五种方式都聊完了最后说一点个人体会。如果让我给一个刚入门的人建议我会推荐先从方式二start.spring.io网页生成把项目跑起来建立感性认识然后找时间完整走一遍方式四Maven手动搭建把底层原理彻底吃透等你在公司里基于公共脚手架开发时方式五复制改造基本就是日常操作了。至于方式一和方式三其实是同一个操作入口下的源地址区别理解了原理之后信手拈来。踩过几次坑之后我现在的习惯是不管用哪种方式创建项目第一件事永远是确认JDK版本和SpringBoot版本匹配第二件事是配好Maven镜像第三件事才是打开欢迎页。版本对了依赖能下载项目基本就成功了一大半。希望这篇总结能帮你把“创建SpringBoot项目”这个看似入门、实则暗坑不少的操作一次趟平。