企业官网建设流程全解析

前两天帮人排查一个启动失败的问题，报错信息是“无效的源发行版：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版本要求和适用人群做了个对比，你看了直接对号入座。

从推荐度来看，如果你用的是Ultimate版且网络正常，无脑用方式一没问题；如果你是社区版用户，方式二就是你的救命稻草；如果你想真正搞懂SpringBoot的自动装配和依赖传递，方式四值得你完整走一遍。至于方式五，那是企业开发里隐藏的高频操作，很多人的新项目不是“创建”出来的，而是“复制改造”出来的。

2. 方式一：IDEA内置向导，官方源生成项目的常规路径

2.1 新版IDEA里的向导入口和配置项

用IDEA自带向导创建SpringBoot项目，不同版本的界面差别还挺大。

老版本IDEA的操作路径是：File -> New -> Project，左侧直接能看到Spring Initializr，然后右侧填Group、Artifact，选Spring Boot版本，勾选所需依赖，最后点Finish就生成完事。

新版IDEA（2020.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.java

DemoApplication这个类是整个项目的入口，它的代码非常简单：

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，绝大多数人用Maven
• Language：Java、Kotlin、Groovy三选一，默认Java
• Spring Boot版本：系统会给你一个默认版本，注意看它要求的JDK版本
• Group：一般是公司域名反写，比如com.example
• Artifact：项目名
• 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.18：

<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.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> <id>aliyunmaven</id> <mirrorOf>central</mirrorOf> <name>阿里云公共仓库</name> <url>https://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 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>2.7.18</version> <relativePath/> </parent> <groupId>com.example</groupId> <artifactId>manual-demo</artifactId> <version>0.0.1-SNAPSHOT</version> <properties> <java.version>1.8</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。它本身不实现业务功能，但它是一个父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.port=8080 spring.application.name=manual-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 -> Rename，IDEA会帮你把整个代码里的包引用一并替换掉。这一步必须彻底做干净，包括测试类里的包名。

第五步，修改配置文件。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.8，Language level选8，Runner里的JRE也选JDK 8，JAVA_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> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> <exclusions> <exclusion> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-tomcat</artifactId> </exclusion> </exclusions> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-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?useUnicode=true&characterEncoding=utf8 username: root password: 123456

context-path这一项经常被人忽略。配置了它之后，所有接口的访问路径都会加上一个统一前缀，比如上面配置了对/api，原本访问/hello的接口就变成了/api/hello。

另外还有一个很实用的小功能，banner生成器。SpringBoot启动时控制台会打印一个ASCII艺术的banner，网上有专门的banner生成网站，可以把自己的项目名、团队名做成字符画，写入src/main/resources/banner.txt里。虽然装饰性大于实用性，但在团队文化上还是能整出点名堂的，很多人喜欢玩这个。

7.4 热部署、打包这类“后处理”内容

开发阶段每次改代码都要重启服务，是很影响效率的，这时候可以给项目加入热部署支持。在pom.xml里添加devtools依赖：

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-devtools</artifactId> <optional>true</optional> </dependency>

加了依赖之后，还需要在IDEA的Settings -> Build, Execution, Deployment -> Compiler里勾选Build project automatically，同时按Ctrl+Shift+A打开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项目”这个看似入门、实则暗坑不少的操作一次趟平。