★ FEATURED ARTICLE 上次有个刚转Java的朋友问我Maven在SpringBoot项目里到底是个什么角色我说你直接用IDEA新建一个SpringBoot项目一路Next根本不需要关心Maven但等你把项目拷到另一台电脑、改版本、加依赖、打包部署的时候不懂Maven就会被卡得死死的。这篇文章我就用Maven从零手写一个SpringBoot-Web项目不靠IDEA的初始化模板自己建目录、自己写pom.xml、自己写启动类一步步拆给你看。整个过程会覆盖工程目录约定、依赖管理原理、三种启动方式、打包部署、以及我踩过的各种版本和配置坑适合刚入门的同学照着抄也适合已经写过项目但对Maven一脸懵的人补课。1. 整体设计与思路拆解先理清Maven和SpringBoot各自干了什么1.1 Maven在SpringBoot项目里到底负责什么很多初学者把Maven和SpringBoot混在一起觉得Maven是SpringBoot的一部分其实两者完全不是一回事。Maven是一个项目管理和构建工具它管的是三件事依赖管理、项目生命周期、目录约定。SpringBoot是开发框架它管的是应用本身的逻辑和自动装配。两者配合的方式很直白Maven负责把SpringBoot相关的jar包拉下来、把项目编译成可执行文件、把依赖打进去SpringBoot负责在运行时用这些jar包启动Web服务。如果你把搭建SpringBoot项目比作装修一套房子Maven就是装修公司的“材料采购和现场调度”SpringBoot是房子的“水电设计图纸”。设计图纸画得再好材料没买到、施工顺序乱了房子照样装不出来。同样的道理你在代码里写了RestController如果Maven没有把SpringMVC的依赖拉进classpath这个注解根本不会被识别项目启动直接报NoClassDefFoundError。另一个容易忽略的点是Maven的“约定优于配置”。它约定好了源码放在src/main/java资源放在src/main/resources测试代码放在src/test/java编译输出到target目录。SpringBoot的启动器、IDEA的Maven插件、云平台的构建流程全都默认按这套约定来找文件。所以从零手写项目时第一步不是写代码而是把目录结构按Maven的规矩搭对后面才不会被各种“找不到主类”“找不到配置文件”之类的问题折磨。1.2 为什么用SpringBoot而不是传统SSH或SSM早些年写Java Web项目标配是SSMSpring SpringMVC MyBatis或者更老的SSHStruts2 Spring Hibernate。那个年代最痛苦的不是写业务代码而是“配置地狱”每个框架都要配一个XML文件配完Spring配SpringMVC配完SpringMVC还要配数据源、事务、视图解析器这些配置互相之间的依赖关系极其隐蔽少配一个扫描包就启动失败而且报错信息有时候跟实际原因八竿子打不着。新手入行光是把SSM环境跑起来就能折腾一两天。SpringBoot的核心理念是“自动配置”。它通过Maven依赖引入一个spring-boot-starter-web然后靠EnableAutoConfiguration机制自动判断classpath里有哪些jar包进而自动帮你初始化内嵌的Tomcat、默认的SpringMVC配置、JSON序列化器、错误处理页等。好处非常直观你不需要自己写web.xml不需要单独安装Tomcat不需要手动装配DispatcherServlet代码里只要有一个Controller就能把HTTP接口跑起来。而且SpringBoot的“starter”机制把Maven依赖的复杂度大大降低了。原来加一个MyBatis要写至少五六个依赖坐标还得小心版本号是否兼容现在引入一个mybatis-spring-boot-starterMaven会一次性把核心包、自动配置模块、其他关联依赖都拉下来。说白了SpringBoot站在Maven的肩膀上把“默认正确”发挥到了极致你只要遵守约定它就给你一套能跑的生产环境。1.3 版本选型JDK、Maven、SpringBoot三者怎么搭不打架版本问题是新手在搭建SpringBoot项目时遇到的第一道坎。我见过不少同学一上来就装了最新的JDK 21、下载了最新的SpringBoot 3.x然后发现网上很多教程里的写法在3.x里走不通比如javax.servlet被换成jakarta.servlet原来的很多配置项也变了心态直接崩。这里分享一套我实测下来最稳的组合JDK 8或11配SpringBoot 2.7.xMaven用3.6.3以上版本。这套组合的生态最成熟网上资料最多各种中间件都兼容踩坑概率最低。如果你确实想尝试SpringBoot 3.x就要明确几条硬边界JDK必须17起步很多老工具包需要升级适配版本代码里引用javax.*的地方要全部换成jakarta.*因为JavaEE捐赠给Eclipse基金会之后换了命名空间。这不是什么疑难杂症但会给初学者带来额外的心智负担所以我给的建议是先跑通2.7.x理解原理再平滑过渡到3.x。Maven版本的选择相对宽松3.6.3到3.9.x都可以正常构建SpringBoot项目。但要注意Maven版本和JDK版本的兼容性如果用JDK 17甚至更高建议Maven不低于3.8.1否则部分插件比如spring-boot-maven-plugin运行时的反射操作可能因为JDK强封装而报错。具体选型可以参考下面的表格组合方案JDK版本SpringBoot版本Maven版本适用场景入门学习JDK 8/112.7.x3.6.3教程丰富兼容性好生产业务JDK 112.7.x3.6.3稳定优先生态成熟新项目尝鲜JDK 173.2.x3.8.1新特性支持注意包名变化保守运维JDK 82.5.x3.6.3老旧系统维护2. 核心细节解析与实操要点目录结构、pom.xml与三驾马车代码2.1 工程目录结构Maven的“约定优于配置”怎么落地不借助IDEA的Spring Initializr第一步就是按照Maven的约定手动创建目录结构。一个标准的Maven父子模块项目长这样springboot-web-demo ├── pom.xml └── src ├── main │ ├── java │ │ └── com/example/demo │ │ ├── DemoApplication.java │ │ ├── controller/HelloController.java │ │ └── service/HelloService.java │ └── resources │ ├── application.yml │ └── static/ (可选) └── test └── java/com/example/demosrc/main/java是源码根目录包名com.example.demo下放启动类和各业务代码src/main/resources放配置文件、静态资源和模板文件src/test/java放单元测试target目录不用自己建Maven执行compile或package时会自动生成。这里有个新手容易犯的错有人把配置文件放到src/main/java下面结果打包后找不到配置。因为Maven默认只把src/main/resources里的文件原样复制到classpath根路径src/main/java里除了.java源码会被编译其他文件不会自动作为资源处理。启动类的包路径也有讲究。DemoApplication.java要放在包的顶层也就是com.example.demo而不是和controller、service平级或者更深。因为SpringBoot自动扫描的默认范围是启动类所在包及其子包如果把启动类放在com.example.demo就能自动扫描到com.example.demo.controller和com.example.demo.service。你要是把启动类挪到某个子包下面Controller和Service在兄弟包或上层包就扫不到接口全404。2.2 pom.xml关键标签拆解parent、starter、插件各管什么pom.xml是Maven工程的心脏也是很多人看一眼就头疼的文件。实际上一个SpringBoot-Web项目的pom.xml核心就三块parent、dependencies、build。逐个拆开讲。spring-boot-starter-parent是一个专门给SpringBoot项目用的父POM。它的作用是统一管理SpringBoot所有官方starter和大量常用第三方库的版本号。你引入某个starter时可以不用写version子POM会从父POM的dependencyManagement里继承到匹配的版本。这就避免了一堆jar包版本号互相冲突的问题。打个比方父POM就是公司统一的“技术选型清单”里面列好了哪个组件用哪个版本你在子工程里只需要说“我要用哪个组件”不用重复写版本。spring-boot-starter-web是Web项目的核心依赖。它内部自动引入了SpringMVC、内嵌Tomcat、Jackson JSON处理库、Spring核心等十来个jar包。starter命名规则很规律spring-boot-starter-xxx比如要访问数据库就加spring-boot-starter-jdbc要做健康检查就加spring-boot-starter-actuator。理解了这种命名规律以后项目需要新功能时就知道该去搜什么关键词。spring-boot-maven-plugin放在buildplugins里它有两个关键作用一是把项目打成可执行的jar包fat jar让java -jar能直接运行二是在开发阶段支持mvn spring-boot:run这条命令直接启动应用。如果没有这个插件mvn package打出来的Jar只是个普通jar依赖不在里面启动时会报ClassNotFoundException。写pom.xml时还有一个细节值得注意groupId、artifactId、version这三个坐标属性理论上你可以随便填比如groupIdcom.example/groupId、artifactIddemo/artifactId、version0.0.1-SNAPSHOT/version。它们主要在项目发布到私有Maven仓库、或者被其他项目作为依赖引入时用来定位你的包。如果只是本地学习这三个值不影响运行。2.3 配置文件的演进application.properties还是application.yml很多老教程都在用application.properties写法是server.port8080这种keyvalue。现在主流项目越来越倾向application.yml因为YAML的层级结构在配置多组数据时更清晰比如配置数据源、Redis、日志级别用缩进展示层级关系比一长串带点的key直观得多。两者本质上等价SpringBoot都能识别同一份配置里也可以混用但混用带来的优先级问题新手容易迷糊最好只选一种。一个最基础的application.yml长这样server: port: 8080 spring: application: name: springboot-web-demoserver.port指定内嵌Tomcat的监听端口默认是8080如果你的电脑上8080被其他进程占用改一个比如8081就好。spring.application.name是给应用起名字做服务注册、日志聚合时用处很大建议从一开始就写上。说到多环境配置熟悉这套之后可以这样组织application.yml里只放公共配置然后按环境拆分application-dev.yml、application-prod.yml在application.yml里用spring.profiles.active: dev指定当前激活的环境。启动时也能动态覆盖比如部署到服务器时用java -jar demo.jar --spring.profiles.activeprod命令行参数优先级最高不用改文件就能切换环境。这个习惯越早养成越好以后对接联调环境和生产环境时就靠这一手。2.4 启动类、Controller与Service的代码要点用Maven手写一个SpringBoot项目的关键代码其实很少三驾马车就三个文件启动类、Controller、Service可选但是推荐加一个。启动类的标准写法是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); } }SpringBootApplication是一个组合注解它把SpringBootConfiguration、EnableAutoConfiguration、ComponentScan合在了同一个注解里。所以只要写了它约定好包路径框架就会自动扫描同包和子包下所有标注了Component、Service、Controller等注解的类注册成Spring容器里的Bean并触发自动配置逻辑。Controller的写法同样简洁package com.example.demo.controller; import com.example.demo.service.HelloService; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RestController; RestController RequestMapping(/api) public class HelloController { private final HelloService helloService; public HelloController(HelloService helloService) { this.helloService helloService; } GetMapping(/hello) public String hello(String name) { return helloService.sayHello(name); } }注意这里我用了构造函数注入而不是Autowired字段注入。Spring官方其实更推荐构造函数注入因为能保证依赖不可变、方便写单测。RestController相当于Controller加ResponseBody意思是这个类里所有接口方法的返回值直接写进HTTP响应体而不是返回视图名。如果你要返回JSON对象返回一个自定义的Result对象SpringBoot会自动用Jackson序列化成JSON里面什么都不用配。如果你用了Controller没加ResponseBody前端访问接口时会被当成找页面模板大概率收到404或者解析模板报错。这两个注解的区别是Web层新手第一坑。Service层用来演示依赖注入package com.example.demo.service; import org.springframework.stereotype.Service; Service public class HelloService { public String sayHello(String name) { String target name null || name.trim().isEmpty() ? World : name.trim(); return Hello, target ! This message is from SpringBoot-Web.; } }Service注册BeanController通过构造函数引入HelloServiceSpring容器会在创建HelloController时把HelloService实例传进来。这一套就是Spring最核心的控制反转和依赖注入思想项目变大之后所有业务逻辑都靠这种模式组织。3. 实操过程与核心环节实现从空目录到可运行jar包3.1 全局配置Maven本地仓库、镜像与JDK编译级别动手建项目之前先把Maven的全局设置文件settings.xml调好。这个文件一般位于Maven安装目录的conf目录下或者~/.m2/settings.xml用户级优先级更高。没有这个文件也没关系可以自己创建一个。里面有三个关键配置值得改动。第一个是本地仓库路径。Maven下载的所有依赖jar包默认存放在~/.m2/repository如果你C盘空间紧张可以改到其他盘。示例localRepositoryD:/maven-repository/localRepository第二个是镜像仓库。中央仓库的服务器在国外直接访问时快时慢国内开发者常用的办法是把依赖下载地址切到阿里云镜像仓库地址是https://maven.aliyun.com/repository/public。配置方式是在settings.xml的mirrors节点里加镜像规则mirror idaliyunmaven/id mirrorOf*/mirrorOf namealiyun public repository/name urlhttps://maven.aliyun.com/repository/public/url /mirrormirrorOf*/mirrorOf表示所有仓库的请求都走这个镜像。配好之后第一次下载SpringBoot依赖的速度会从十几分钟缩短到一分钟左右。注意只是说常规的Java依赖仓库加速不涉及其他网络配置。第三个是JDK编译级别。Maven默认用JDK的版本作为编译等级但如果你的机器装了JDK 17而项目希望以Java 8语法兼容运行就需要在pom.xml的properties里声明properties maven.compiler.source1.8/maven.compiler.source maven.compiler.target1.8/maven.compiler.target /properties这样Maven编译时会把源码当作Java 8的语法级别编译产出的class字节码版本也是Java 8可以跑在JDK 8及以上的JVM上。但这个设置只影响编译期的语法和字节码版本运行时的JDK还是由java -jar命令的java决定。3.2 最小组件的手写工程与逐行讲解我直接给出一份完整的最小pom.xml。注意这里不需要借助任何脚手架复制到txt里改个名就能用?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 groupIdcom.example/groupId artifactIdspringboot-web-demo/artifactId version1.0.0/version packagingjar/packaging parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.7.18/version relativePath/ /parent properties java.version1.8/java.version maven.compiler.source1.8/maven.compiler.source maven.compiler.target1.8/maven.compiler.target project.build.sourceEncodingUTF-8/project.build.sourceEncoding /properties dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-test/artifactId scopetest/scope /dependency /dependencies build plugins plugin groupIdorg.springframework.boot/groupId artifactIdspring-boot-maven-plugin/artifactId /plugin /plugins /build /projectpackagingjar/packaging也可以不写因为默认就是jar。relativePath/这个空标签意思是不要向上级目录查找父POM直接从Maven仓库获取可以让项目构建不被父路径干扰。spring-boot-starter-test只用scopetest/scope标记表示它只在单元测试编译和运行阶段使用不会打进最终产物。把上一节里的启动类、HelloController、HelloService、application.yml按目录结构放好之后在项目根目录打开命令行执行mvn clean compile如果一切顺利你会看到target/classes里生成了编译后的class文件。这一步能确认pom.xml和代码环境没问题。然后再执行mvn spring-boot:run控制台出现Started DemoApplication in xxx seconds就说明项目启动成功浏览器访问http://localhost:8080/api/hello?nameJava页面会返回Hello, Java! This message is from SpringBoot-Web.。到这里一个不依赖IDE模板的SpringBoot-Web最小系统就跑通了。3.3 三种启动方式对比与真实使用场景同一个SpringBoot项目有三种启动方式它们的底层逻辑完全一样但使用场景各不相同。第一种在IDEA里直接运行DemoApplication的main方法。日常开发时用的最多因为支持断点调试、热重载而且IDEA会自动加载Maven依赖。第二种命令行运行mvn spring-boot:run。这种方法适合在没有IDE的服务器上临时跑项目或者想验证pom.xml配置是否正确时使用。第三种先执行mvn clean package -DskipTests打成jar包再运行java -jar target/springboot-web-demo-1.0.0.jar。这是生产环境的标准部署方式。三种方式之间有个容易踩坑的差别开发时用IDE或spring-boot:runclasspath里包含target/classes和所有依赖但用java -jar运行时依赖全部被spring-boot-maven-plugin重新组装进了jar包内部的BOOT-INF/lib目录。如果直接对没有经过SpringBoot插件重打包的普通jar执行java -jar会提示no main manifest attribute这个问题不是代码问题而是打包方式不对。顺带一提-DskipTests跳过的是测试执行但测试代码仍然会编译如果想连编译都跳过用-Dmaven.test.skiptrue。日常构建我一般用-DskipTests因为编译一遍测试代码能让语法错误尽早暴露。3.4 打包后的部署细节端口覆盖、外部配置与后台启动jar包构建好之后生产部署时经常需要动态调整配置。SpringBoot提供了非常方便的外部化配置机制命令行参数优先级高于配置文件。比如你想临时换端口java -jar target/springboot-web-demo-1.0.0.jar --server.port9090这种方式的优先级排在外置配置文件之前而且环境变量SERVER_PORT9090也能达到类似效果。如果想把整个application.yml放到jar包外部来维护可以在jar包同目录下建一个config文件夹把配置文件丢进去。也可以直接传--spring.config.location/path/to/application.yml。SpringBoot读取配置的优先级秩序大概是命令行参数大于外部配置外部配置大于jar包内配置jar包内配置大于默认值。理解这个顺序部署时就不用反复“重新打jar只为了改个端口”了。在Linux服务器上后台运行最朴素的命令是nohup java -jar springboot-web-demo-1.0.0.jar --spring.profiles.activeprod app.log 21 nohup和配合让应用脱离终端 app.log把控制台日志重定向到文件21把报错信息也一并写入。查看进程用ps -ef | grep springboot停应用用kill -9 端口PID但正式环境建议用actuator/shutdown优雅停机当然那是后话了先把这套基础跑稳。4. 常见问题与排查技巧实录这些坑我基本都踩过一遍4.1 依赖下载失败与镜像配置问题第一个高频问题是依赖下载失败报错大致长这样Could not transfer artifact ... Connection timed out。这种问题十有八九是连接Maven中央仓库超时。解决办法就是我前面说的在settings.xml里配阿里云镜像。配完之后如果依然失败还有一个隐藏原因本地~/.m2/repository里已经存了一份损坏的*.lastUpdated缓存文件。Maven看到这个标记会认为该依赖已尝试下载过但失败了短期内不会重新拉取。解决方法是删除该依赖对应的*.lastUpdated文件再重新构建。用IDEA的时候还可以在Maven工具窗里点“重新加载所有项目”让IDEA强制刷新依赖索引。还有一个小细节是有些公司内部用私有Nexus仓库域名是内网IP这时本地仓库可以正常下载但换同事电脑就失败。遇到这种情况检查settings.xml里的mirror和profile配置是否和项目一致。我们团队早期就踩过“代码能提交但同事拉下来依赖全红”的坑最后发现是有人本地配了全局mirrorOf *覆盖了私服地址。4.2 端口被占用与启动自动换端口的假象启动SpringBoot Web项目时最常见也最迷惑人的错误就是Port 8080 was already in use。有的人图省事顺手把server.port改成随机端口SpringBoot确实支持server.port0表示随机端口启动日志里会打印实际端口但这会带来一连串问题你没法提前告诉别人你的服务跑在哪个端口也不好配网关转发规则。所以除非本地联调冲突不建议用随机端口。排查端口占用的标准流程Windows下执行netstat -ano | findstr 8080Linux下执行netstat -tunlp | grep 8080或者lsof -i:8080找到PID后再去任务管理器或kill -9结束进程。有时候是上次项目没关干净残留的Java进程这种情况下把进程杀掉再启动就好。4.3 启动成功但访问接口404项目启动日志显示Started DemoApplication但浏览器访问http://localhost:8080/api/hello却404这是初学者的高频困惑。排查顺序我建议先看三处。第一处是启动类的位置。如果DemoApplication没有放在包路径的顶层比如错误地放在了com.example.demo.controller包里那么SpringBootApplication默认的组件扫描只会扫com.example.demo.controller及其子包controller和service可能扫不到接口自然不注册。第二处是Controller注解。如果类上用的是Controller而没有在方法上写ResponseBodySpringMVC会认为你要返回视图名找不到对应的模板返回的错误偶尔不是404而是500或JasperException但效果上都不是返回JSON。第三处是访问路径拼写。RequestMapping(/api)加上GetMapping(/hello)意味着完整路径是/api/hello直接访问/hello当然404。看日志最稳SpringBoot启动日志里有一行Mapped {[/api/hello],methods[GET]}看到它就能确认接口是真的注册了。4.4 热部署与开发体验优化开发阶段每次改代码都要手动重启应用时间一长非常消耗耐心。SpringBoot提供了spring-boot-devtools这个开发辅助库引入后支持自动重启dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-devtools/artifactId scoperuntime/scope optionaltrue/optional /dependencyoptionaltrue/optional很关键表示这个依赖不会被传递到下游项目也不会进入生产jar包。加上这个依赖之后IDEA里按一次快捷键让项目重新编译应用会自动重启。但这里有个细节devtools默认会对classpath下的文件变更做触发判断如果IDE没有开“自动编译”你改了代码不按CtrlF9它也不会重启。另外重启和“热替换”不同devtools实际上还是重启应用只是比手动快一些。如果需要复杂的热替换比如动态代理类改变而不重启就得靠JRebel之类的商业工具开发阶段按需选择就行。4.5 版本冲突与jar包诡异问题SpringBoot项目中出现ClassNotFoundException或者NoSuchMethodError往往不是代码问题而是依赖版本冲突。最常见的场景是你在pom.xml里手动引入了某个第三方库没指定版本或者指定了一个跟SpringBoot默认版本不一致的版本导致spring-boot-starter传递性依赖和你的依赖发生对抗。解决这类问题的标准动作是先看依赖树mvn dependency:tree命令会把所有依赖及其版本打印出来配合mvn dependency:tree -Dincludesorg.springframework:spring-core可以精确过滤查看某个组件的版本来源。NoSuchMethodError尤其让人摸不着头脑因为编译期是好的运行期却告诉你某个方法不存在。本质原因是classpath里有两个同名但不同版本的jar包JVM加载到的是老版本而代码里调用了新版本才有的方法。排查思路就是用mvn dependency:tree找出重复依赖再用exclusions把不必要的传递性依赖排除掉。这是Maven的高级玩法初期遇到这类问题不用慌先看依赖树、再逐个排除基本就能解决。如果实在排查不清可以下载一个dependency-analyze插件辅助分析。4.6 从jar包反解出项目结构的实用技巧热搜词里有一个问“怎么将springboot jar反编译成项目”这个需求背后的动机一般是想理清一个可运行jar的内部结构或者想找某个类看它的实现。SpringBoot可执行jar包内部结构是固定的BOOT-INF/classes存放你自己的编译产物和资源文件BOOT-INF/lib存放所有依赖jar包META-INF/MANIFEST.MF里指定了启动器和主类。理解这个结构有个很大的好处你部署时如果发现NoClassDefFoundError可以先执行jar tf app.jar | grep 具体的类名确认这个类到底有没有被打进包里。如果想看某个类的源码可执行jar里的class是编译后的字节码直接用文本工具打开是乱码需要反编译工具比如JD-GUI或者IDEA的Java Decompiler插件。反过来把BOOT-INF/classes里的内容替换成自己修改后的class文件再用jar uf命令更新到jar包里也能实现“修个线上问题不用重新构建整个项目”的效果。不过这只是应急手段正规做法还是改完代码重新打包发布。我用这种技巧的场景一般是产品环境上一个老jar包架构文档没了我只能从jar里逆向确认它内部拆了几个模块、用了哪些依赖。写在最后的一个实用建议项目跑通之后我建议你把这一套流程多手打两遍直到不需要看教程也能默写出pom.xml骨架和启动类。别嫌基础Maven和SpringBoot的关系就像盖楼时脚手架和图纸的关系脚手架绑得稳后面往上盖多少层都有底气。我见过不少工作两三年的同事遇到“依赖怎么拉不下来”“打包出来为什么跑不了”这类问题还要现查资料就是因为刚入门时靠IDE一路Next把这一步跳过去了。如果你后续想加数据库、Redis、消息队列记住一条规律先去搜xxx-spring-boot-starter引入依赖后基本只需要配application.yml剩下的交给自动化配置。这个套路在SpringBoot生态里几乎一劳永逸。下次遇到所谓“新的框架”你会发现它本质上就是又多了一个starter而已。
阅读完成 · 觉得有帮助？
