1. SpringBoot是什么能做什么SpringBoot是我个人这几年在Java后端开发里用得最痛快的框架没有之一。它不是一个全新的技术体系而是把Spring家族里那些繁琐的配置、复杂的集成过程给重新封装了一遍。说得直白一点如果没有SpringBoot你哪怕只想搭一个能处理HTTP请求的最简单的Web服务也得先搞定Spring核心、SpringMVC、Jackson、Tomcat、日志组件这些再把它们之间的依赖关系和版本号理清楚然后写一堆web.xml、applicationContext.xml、spring-mvc.xml中间任何一个环节版本对不上启动的时候就是一个又一个ClassNotFoundException在那儿等着你。SpringBoot要做的事情就是把这堆闹心事干掉。你只需要在pom.xml里引入一个spring-boot-starter-web它自动把Web开发需要的那一串依赖全部拉进来还用默认配置把它们串好了。你在IDEA里新建一个项目写一个带RestController的类然后运行那个带main方法的入口类Tomcat端口8080就起来了你的接口就能被访问了。整个过程不需要部署任何外部Tomcat不需要写一行XML配置前后也就几分钟。这些特性加起来解决了一个很实际的问题让一个Java开发者的注意力从纠结配置文件和依赖版本号转移到业务代码本身。尤其是刚入门的新人用SpringBoot学Spring路径会平滑非常多。这篇内容我给它的定位就是一份入门地图——你不需要记住每个细节但你需要搞清楚SpringBoot的底层逻辑、启动原理、以及那些在面试里反复出现的核心概念是怎么回事。看完你能独立创建一个SpringBoot项目能看懂基本配置的含义能在遇到报错的时候有排查思路就达到目标了。这个系列后续会不断往下深入从自动配置原理到集成Redis、消息队列、工作流引擎、多数据源都会陆续展开第一章的定位就是把地基打牢。2. 环境准备与版本选择2.1 最稳的JDK与SpringBoot版本组合网上关于springboot版本太高的吐槽我见得特别多。很多新人直接在官网下载最新版SpringBoot然后项目建完一跑报各种莫名其妙的错——比如IllegalArgumentException、Unsupported class file major version 61其实大部分情况下不是代码问题是JDK和SpringBoot版本不匹配。我目前长时间用的是SpringBoot 2.7.x配上JDK 1.8或者JDK 11。这个组合是目前国内企业环境里最稳的搭配教程多、排错资料多、周边组件的兼容性测试也做得最充分。SpringBoot 3.x开始强制要求JDK 17以上而且底层换成了Jakarta EE命名空间很多老项目的javax包名要整体改成jakarta如果不是新项目没必要一上来就追这个版本。如果你的机器上装的是JDK 21、JDK 17这种比较高的版本想回退到1.8我建议别只改IDEA里的Project SDK还要检查三处File - Project Structure里的Project和Modules的SDK、Settings - Build Tools - Maven - Runner里的JRE、以及pom.xml里java.version这个属性。三个位置不一致编译的时候照样报版本错误。用Maven管理依赖的话pom.xml里需要显式加这一段指定编译级别properties java.version1.8/java.version maven.compiler.source1.8/maven.compiler.source maven.compiler.target1.8/maven.compiler.target /properties版本固定的前提下父工程的版本坐标直接这样声明parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.7.13/version relativePath/ /parent用spring-boot-starter-parent作为父工程最大的好处是它声明了一个完整的BOMBill of Materials也就是整个Spring生态里几百个库的版本号全都帮你定好了。你自己引入Spring相关依赖的时候不需要也不应该再写version写多了反而容易和BOM里的版本冲突。2.2 IDEA创建项目的两种常用方式现在几乎所有Java开发都用IDEA来建SpringBoot项目。比较直观的方式是File - New - Project - Spring Initializr左边选Spring Boot版本右边勾选需要的依赖比如Web、MyBatis、Lombok、MySQL Driver然后点FinishIDEA会联网从Spring Initializr官网拉取工程骨架项目结构和Maven配置一次性给你生成好。但这里有个新手高频翻车点国内网络环境下IDEA连Spring Initializr经常超时导致项目创建卡在进度条那里。解决办法是先把https://start.spring.io替换成阿里云的镜像地址https://start.aliyun.comIDEA里在Settings - Build, Execution, Deployment - Build Tools - Maven - Repositories或者直接在新建项目向导里改Service URL就行。阿里云镜像速度快很多能少踩不少坑。第二种方式是先建一个空的Maven项目然后在pom.xml里手动补齐SpringBoot的parent、依赖、构建插件。这种方式虽然麻烦一点但对理解SpringBoot的依赖管理方式非常有帮助。我当年第一次这么干的时候才真正搞明白starter到底帮我们干了什么活。为了保险起见建议你在Maven的settings.xml里配置好阿里云仓库镜像这样即使项目建好了第一次拉取依赖的时候也不会因为网速或者仓库访问问题卡住mirror idaliyunmaven/id mirrorOfcentral/mirrorOf name阿里云公共仓库/name urlhttps://maven.aliyun.com/repository/public/url /mirror依赖下载这块多说一句第一次创建项目时Maven会拉取大量jar包少的几十个、多的一百多个如果本地仓库没有缓存这一步会等很久。在IDEA右下角能看到下载进度如果下载特别慢记得检查是不是镜像没配置好。3. 第一个SpringBoot项目的诞生3.1 从零到能跑一个带Web接口的最小项目我直接用实际项目来演示。假设你用的是SpringBoot 2.7.13 JDK 1.8在IDEA里新建Spring Initializr项目Group填com.example、Artifact填helloboot依赖勾选Spring Web然后等项目生成完展开src目录你会看到这样几个关键文件HellobootApplication.java这个就是启动类带SpringBootApplication注解里面有标准的main方法一切从这个类开始。application.properties默认是空文件后面所有自定义配置都写在这里。src/test/java下的测试类用SpringBootTest标注的空测试类先不用管它。启动类长这样SpringBootApplication public class HellobootApplication { public static void main(String[] args) { SpringApplication.run(HellobootApplication.class, args); } }注意一个容易踩坑的点SpringBoot默认会扫描启动类所在包及其子包下的所有组件。也就是说如果你的启动类在com.example.helloboot包下面那么com.example.helloboot.controller、com.example.helloboot.service、com.example.helloboot.mapper这些子包里的Controller、Service、Repository、Component都能被自动扫描到。但如果你在启动类外面建了包比如com.example.common那里面即使写了注解也不会被注册成Bean启动不会报错但接口就是404这个问题当年卡了我差不多半天。接下来写一个最简单的接口建一个HelloController类RestController public class HelloController { GetMapping(/hello) public String hello() { return Hello SpringBoot!; } }RestController是Controller加ResponseBody的组合注解意思是你这个类里每个方法返回的字符串会自动被序列化成HTTP响应体不需要再额外加ResponseBody。GetMapping(/hello)是RequestMapping(value/hello, methodRequestMethod.GET)的缩写等价写法只是短了很多。直接运行HellobootApplication的main方法IDEA控制台会滚动日志。能看这一行就说明启动成功了Tomcat started on port(s): 8080 (http) with context path 然后浏览器访问http://localhost:8080/hello页面上显示Hello SpringBoot!。到这里第一个SpringBoot项目就跑起来了。整个过程没有配置任何XML、没有部署任何外部容器这就是SpringBoot对开发者最直观的解放。3.2 项目结构拆解这些目录和文件到底是什么很多人项目跑起来后就急着往下写代码反而忽略了项目结构本身带着的信息量。我建议把SpringBoot项目结构再看细一点把骨架的含义搞清楚后面做工程化项目会顺手很多。目录/文件职责面试高频点src/main/javaJava源码目录启动类所在包即扫描根包src/main/resources配置文件目录application.yml / static / templatessrc/main/resources/application.properties核心配置文件端口、数据源、日志等src/test/java测试代码目录依赖注入、MockMvc测试pom.xmlMaven项目描述文件依赖管理、构建配置application.properties是早期SpringBoot默认使用的配置文件现在更多人喜欢用application.yml。YAML格式用缩进表达层级关系读起来更清晰比如配一个数据源server: port: 8081 spring: datasource: url: jdbc:mysql://localhost:3306/test?useSSLfalsecharacterEncodingutf8 username: root password: root123 driver-class-name: com.mysql.cj.jdbc.Driver注意YAML用冒号后面必须跟一个空格否则启动解析配置的时候直接报错。这种错误在IDEA里其实会有提示但很多人会忽视IDEA对YAML文件的校验盯着控制台的factoryBeanName之类报错信息看半天才发现是配置文件格式问题。application.properties和application.yml虽然格式不同但他们属于同一套配置体系。如果两个文件同时存在IDEA会给出警告实际上application.properties的优先级更高这不是乱定的SpringBoot对配置文件的加载顺序有一套完整的规则。这部分后面展开讲自动配置原理的时候会细说。static目录用来放静态资源比如HTML页面、CSS、JS、图片templates目录用来放模板文件如果使用Thymeleaf或者FreeMarker的话。这里有个很容易搞混的点SpringBoot项目默认打包成jar包不是war包所以这些静态资源是放在classpath下的而不是传统Web项目里的webapp目录。只有你明确把项目改成war包部署到外部Tomcat的时候webapp目录才有意义。3.3 修改端口和自定义Banner的小技巧把application.properties里加一行server.port8081重启项目端口就变成8081了。这个在本地同时开多个项目调试时很常用比如后端工程占8080另外一个管理后台占8081。SpringBoot还有一个很有人情味的设计启动的时候控制台会打印一个ASCII Art的Banner就是那个大大的Spring图案。如果你觉得默认的太丑或者想加一点个性化很多人会用Banner生成器网上搜索SpringBoot banner生成器就能找到可用工具把生成出来的字符画粘贴到src/main/resources/banner.txt里重新启动项目就能看到效果。有个细节值得说一下banner.txt文件如果编码不是UTF-8启动时控制台可能出现乱码生成器生成的文本建议用IDEA右下角把文件编码改成UTF-8再保存。这个虽然不影响运行但控制台一堆乱码还是会影响调试心情。如果你想关掉Banner在main方法里这样写SpringApplication app new SpringApplication(HellobootApplication.class); app.setBannerMode(Banner.Mode.OFF); app.run(args);4. 注解体系速览先认识这些够用了4.1 核心注解及其分工SpringBoot的注解体系是学习过程中必须跨过的一道坎很多人在网上搜springboot常用注解通常带着面试意图。我的建议是先记住最常用的这几个把分工逻辑搞清楚再往下延伸。Controller层相关的上面已经用到了RestController和GetMapping。它们的整体结构是这样RequestMapping最基础的映射注解可以标注在类上定义统一前缀也可以标注在方法上定义完整路径。GetMapping、PostMapping、PutMapping、DeleteMapping分别是RequestMapping配合指定HTTP Method的缩写形式语义清晰。RequestParam绑定单个请求参数比如RequestParam(name) String name如果你不想让参数必填需要配置required false或者给一个defaultValue不然前端少传一个参数就直接报400。PathVariable绑定URL模板里的变量/user/{id}这种路径取值用的就是它。Service层和Repository层常见的Service标记业务层组件。Repository标记数据访问层组件还能额外转换底层持久化框架抛出的异常。Component通用组件注解不属于Controller、Service、Repository里面任何一类的时候用它就行。依赖注入相关的Autowired按类型自动注入SpringBoot里最常用。如果一个接口有多个实现类还需要配合Qualifier指定具体哪个实现。ResourceJDK自带的注解按名称注入这是它和Autowired最大的区别。配置相关的Configuration标记一个类为配置类相当于传统Spring里的XML配置。Bean在配置类里声明一个Bean实例经常用来手动组装那些没法用Component扫描的第三方库对象。Value读取配置文件里单个配置项的值Value(${server.port})这样用。ConfigurationProperties批量绑定配置项到Java对象的属性这个后面会重点讲因为它是SpringBoot正确处理配置的关键姿势。4.2 ConfigurationProperties到底解决了什么问题很多人一开始嫌ConfigurationProperties麻烦觉得我用Value一个值一个值取不也挺好的吗早期确实有这种做法我也这么干过。但等到配置项一多比如短信服务需要配accessKey、secretKey、signName、endpoint总共五个参数你在五处业务代码里各用一个Value后面哪个参数改了名字就要全文搜索着改。这种体验真的不怎么样而且很难测试。ConfigurationProperties解决的就是配置的集中管理和类型安全绑定。建一个配置类Component ConfigurationProperties(prefix sms) public class SmsProperties { private String accessKey; private String secretKey; private String signName; private String endpoint; // getters and setters 必须写否则绑定不进去 }然后在application.yml里sms: access-key: LTAI4xxxx secret-key: xxxxxx sign-name: 学习测试 endpoint: dysmsapi.aliyuncs.com这里有一个容易踩的坑配置文件里用中划线access-keyJava属性里用驼峰accessKeySpringBoot的Relaxed Binding规则会自动把这两种风格对应起来不用手动处理。但Java类里一定得有对应的getter和setter否则属性绑不进去而且不会有任何报错提示等到调用的时候发现全是null排查起来相当痛苦。在SpringBoot 2.2版本以前使用ConfigurationProperties还需要额外加一个Component或者通过EnableConfigurationProperties(SmsProperties.class)在配置类里激活。新版本里这两种方式都可以。实际项目里我更推荐用EnableConfigurationProperties方式因为这样配置类不用交给组件扫描语义更清晰也方便在依赖库里复用。5. 自动配置原理面试和实战都绕不过去的核心5.1 从SpringApplication.run()说起很多网上找的笔记和面经都提到springboot自动配置原理这是SpringBoot最核心的机制。理解它不需要背诵源码关键是搞懂SpringBoot启动的时候到底做了什么。入口在SpringBootApplication这个组合注解上。它其实是三个注解的集合SpringBootConfiguration本质上就是Configuration表示这是一个配置类。EnableAutoConfiguration自动配置的总开关核心中的核心。ComponentScan默认扫描当前类所在包及其子包下的所有组件。EnableAutoConfiguration内部通过Import(AutoConfigurationImportSelector.class)引入了一个选择器。这个选择器做的事情简单说就是在你引入的jar包里去查找META-INF/spring.factoriesSpringBoot 2.7及以前或者META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.importsSpringBoot 2.7之后新增文件。这些文件里列了一长串的自动配置类比如ServletWebServerFactoryAutoConfiguration负责帮你启动内嵌TomcatDataSourceAutoConfiguration负责帮你配置数据源HttpMessageConvertersAutoConfiguration负责帮你做好JSON转换。你想象一下这个过程你只是引入了一个spring-boot-starter-web它把所有相关的jar包都拉进来了。某个jar包里带着一个spring.factories文件文件里写着一堆自动配置类的全限定名。SpringBoot启动时把这些类名全部读取出来逐个判断要不要生效生效的条件由类上的Conditional系列注解决定。比如RedisAutoConfiguration上面通常会有一个ConditionalOnClass(RedisOperations.class)意思是只有当RedisOperations这个类存在于classpath里这个自动配置才会生效。如果你没引入Redis相关的依赖这个类就不存在自动配置自然跳过。5.2 自动配置类为什么需要条件注解条件注解是自动配置这套机制能够成立的基石。如果没有它们每次启动项目都会尝试把所有自动配置全部加载一遍然后各种Bean之间互相冲突那整个框架就变成一个灾难了。常见的条件注解和它们的含义整理一下注解生效条件ConditionalOnClassclasspath里存在指定类时生效ConditionalOnMissingBean容器里不存在指定Bean时生效ConditionalOnProperty配置文件中存在指定配置项时生效ConditionalOnWebApplication当前应用是Web应用时生效这个设计能带来的好处用一个实际场景说明SpringBoot自动配置了一套默认的RedisTemplate但是如果你自己在项目里定义了一个自定义的RedisTemplate比如为了设置key的序列化方式自动配置看到容器里已经有这个类型的Bean了通过ConditionalOnMissingBean判断它就不会再创建自己的那个默认Bean。也就是说框架提供的默认行为给了你兜底但你仍然可以按需覆盖两边不冲突。这背后也解释了为什么SpringBoot项目里约定大于配置这句话道理在哪里。默认配置不是死板的而是设计成可替换的。你在网上看到所谓SpringBoot开发中一个奇怪的报错明明我写了RedisConfig配置类但为什么还是用了默认配置十有八九是自定义Bean的方法名和自动配置里的Bean名称冲突或者条件注解生效的顺序问题导致的。5.3 与SpringMVC的区别和联系很多人会把SpringBoot和SpringMVC搞混或者在面试的时候被问到SpringBoot和SpringMVC有什么区别的时候不知道怎么组织语言。从关系上看纯粹是层级包含关系。Spring MVC是Spring Framework的一个Web模块它提供了一套完整的基于Servlet的Web开发模式DispatcherServlet是它的核心处理器。SpringBoot则是一个基于Spring生态的快速开发框架它内置了Spring MVC还帮你把DispatcherServlet的装配过程自动完成了。也就是说你写Controller、RequestMapping这些注解的时候背后的运行机制依然是Spring MVC在支撑。传统SpringMVC工程要部署流程大概是写一个DispatcherServlet的初始化类用WebApplicationInitializer或者web.xml注册配置ContextLoaderListener加载Spring根容器配置InternalResourceViewResolver做视图解析再配置静态资源映射最后打war包扔到外部的Tomcat的webapps目录下面启动Tomcat才能访问。SpringBoot把上述全流程的默认实现都预置好了依赖自带的SpringBoot内嵌Tomcat所以你要做的就是写业务类。SpringBoot和SpringMVC不是同层次的东西一个是快速开发框架一个是Web开发组件。如果面试时只记住了这句话说明理解还停留在表面。能把传统SpringMVC工程改造成SpringBoot工程才是真的把两者的关系吃透了。5.4 传统SpringMVC工程如何平滑迁移到SpringBoot从老项目往SpringBoot迁移是一个实际工作中很常见但网上教程很少系统的需求。我自己的经验是遵循这几个步骤来做出错率不高。第一步把web.xml里注册的DispatcherServlet、CharacterEncodingFilter这类东西全部删掉因为SpringBoot自动配置会帮你完成这些。第二步把spring-mvc.xml里配置的组件扫描、视图解析器、静态资源映射等迁移到SpringBoot的配置类通常用Configuration加Bean方式来声明。第三步把applicationContext.xml里配置的数据源、事务管理器迁移到application.yml里或者用MapperScan注解在启动类上指定Mapper接口扫描路径。第四步把原来的log4j.properties或logback.xml做兼容性调整看日志格式和滚动策略是否还需要自定义。第五步原项目如果是war包部署的先改成SpringBoot的jar包方式运行本地跑通了再考虑要不要保留外部容器部署。这个过程中最常见的问题是迁移后启动报No qualifying bean of type错误原因通常是原来靠XML配置扫描的包路径和SpringBoot启动类的扫描路径不一致。解决办法是检查ComponentScan或SpringBootApplication的扫描范围或者干脆把原来的包路径直接放到启动类所在包下。另外一个坑是老项目里如果有自定义的WebMvcConfigurerAdapter这个类从Spring 5开始已经被标记为过时SpringBoot 2.x里要用WebMvcConfigurer接口。6. 常见问题与经验技巧实录6.1 几个高频报错及排查思路按我的经验SpringBoot新手遇到的报错翻来覆去就那么几类。把它们归类整理成一个速查表出了问题直接对号入座效率会高很多报错特征可能原因排查方向Failed to configure a DataSource引入了JPA/MyBatis依赖但没配置数据库连接pom.xml里是否引入了数据库相关starterapplication.yml里是否漏配url/username/passwordWhitelabel Error Page / 404Controller类没有被扫描到或路由写错检查Controller所在包是否在启动类同级或子包下检查请求的URL是否和GetMapping完全一致Port 8080 was already in use端口被占用找个空闲端口改server.port或者用命令行工具查占用进程并结束它Consider defining a bean of type XxxServiceService接口没有实现类或实现类没加Service检查实现类注解和包扫描范围APPLICATION FAILED TO START某个自动配置你明确不需要但它在尝试生效定位具体阻断了哪个配置用exclude排除ClassNotFoundException: jakarta.servlet.*SpringBoot 3.x和旧代码不兼容检查代码里的javax是否要改成jakarta或者直接回退到2.7.x端口占用这个我想单独说一下因为实在太常见了。Windows下用netstat -ano | findstr 8080查出来占用进程的PID再打开任务管理器结束对应进程。Mac环境下用lsof -i :8080查PID然后kill -9干掉它。我遇到过不止一次其实不是真正有进程占用了端口而是之前用IDEA启动的项目没有完全停止关掉IDEA的Stop按钮后后台进程还在跑去任务管理器结束对应的java进程就行。6.2 配置文件的加载顺序和覆盖优先级application.yml和application.properties的加载优先级以及外部配置和内部配置谁说了算在实际部署的时候经常让人头疼。SpringBoot的配置加载顺序遵循一个总原则外部配置覆盖内部配置越具体的配置优先级越高。从高到低大致是这样的顺序命令行参数java -jar app.jar --server.port9090优先级最高然后是SPRING_APPLICATION_JSON环境变量里的配置再下来是application-{profile}.yml和application.yml最低的是Jar包内部的默认值。这个顺序意味着什么本地开发时端口想用8080就可以直接用8080把配置写在application.yml里什么都不用管。但上线部署的时候运维不想改代码里的配置文件那直接在启动命令后面加一个--server.port9090参数就能完成端口替换不用重新打包。理解了这套优先级规则日常开发里的大多数为什么我的配置没生效问题都能自行定位。多环境配置方面如果一个项目要同时支持开发、测试、生产三个环境建三个配置文件application-dev.yml、application-test.yml、application-prod.yml然后在主配置文件里通过spring.profiles.activedev指定当前生效的是哪一套。6.3 关于IDE和构建工具的一些经验Gradle和Maven在SpringBoot项目里都能用IDEA对两种构建方式的支持都不错。但国内企业里Maven的使用率要远高于Gradle原因是Maven仓库源阿里云镜像在国内访问速度稳定团队里新人上手也快。Gradle的优势是构建速度快、脚本灵活适合大型项目或者对构建性能有要求的场景。如果是个人学习项目选Maven就好网上能查到的资料和执行方案最多。等把SpringBoot弄熟了再去玩Gradle也不迟。用VS Code启动SpringBoot项目也是可以的装好Java扩展包、Spring Boot Extension Pack之后直接打开项目让VS Code自动识别Maven项目结构然后在HellobootApplication.java里点运行按钮。如果你能在VS Code里把SpringBoot项目跑起来说明你对项目本身的把握已经很扎实了因为这些支持IDE的扩展本质都是在做同样的事情。但对刚开始学的人来说我还是推荐IDEA毕竟它对SpringBoot的支持是最完整的社区版对SpringBoot项目也是免费支持的。6.4 针对于SpringBoot学习路线的一些实在建议看视频课学SpringBoot很多人记了厚厚一本笔记看完还是不知道从哪开始写代码。我自己的实践经验是两个办法最有效。第一个办法是自己动手搭一个完整项目哪怕是超市收银系统或者备忘录这种极小的项目。搭的过程中你会把创建项目、配置数据源、写CRUD接口、处理统一异常这些环节全部走一遍踩完这些坑再去谈其他高级特性底子就是实的。第二个办法是照着官方文档里的章节结构来组织自己的知识体系。SpringBoot官方文档的目录设计得很经典先讲SpringApplication、再讲外部配置、然后是各类Starter的集成。你把这个顺序当作学习的章节目录比到处搜零散的博客要系统得多。网上关于狂神说SpringBoot笔记之类的资源很多讲得也确实不错适合入门。但我要提醒一下入门视频可以看记笔记也可以但一定不要停留在看懂了的状态。正因为SpringBoot封装程度高你在界面上点几下就能跑起来一个项目反而容易产生我会了的错觉。只有当你动手写、动手配、动手排错的时候才能真正建立起对这套框架的理解。我个人踩过最大的坑就是刚开始学的时候一路跟着教程跑跑通了就觉得自己会了结果面试被问到SpringBootApplication背后是什么支支吾吾半天说不出个所以然。7. 写在后面的一些个人体会我最初接触SpringBoot的时候其实经历了一段适应期。因为以前用惯了SpringMVC加XML配置总觉得配置写在类里不如集中在一份XML里好管理。后来真正在一个项目里用SpringBoot做了两个月的开发之后这个想法彻底转变了。配置跟着代码走改动的时候上下文更完整排查问题的时候不用在多个文件之间来回跳转这种体验的提升是实打实的。说到这再分享一个小技巧SpringBoot启动日志里的INFO级别内容很多人会忽略但里面其实藏了很多信息——比如它帮你加载了哪些自动配置类Positive matches、排除了哪些Negative matches、内嵌Tomcat的端口和上下文路径是什么。排查问题的时候开启debugtrue看这些信息能帮你节省大量时间。学会主动去看启动日志是学会SpringBoot之后很有用的一个习惯。这个系列第一章到这里该讲的核心内容基本覆盖了。下一章我打算聊SpringBoot的配置文件体系和多环境下的优雅管理方式那是从能跑到能上线之间比较重要的一课。