我常被问到一个很基础但很多人没真正搞懂的问题Tomcat干嘛的更准确地说Spring Boot项目里那个内嵌Tomcat到底是什么它和单独下载安装的Tomcat有什么关系为什么明明可以在应用里直接启动却还有一堆教程教人装Tomcat、配Tomcat。这篇东西就是围绕这个核心写的从零把一个Spring Boot应用跑起来把内嵌Tomcat的配置原理讲明白再把我实际用过踩过的坑全部摆出来。内容适合刚接触Spring Boot的新手也适合那些已经抄过不少配置但没时间深究的同学。我会带着你从它是什么走到怎么调最后还会附上我亲手踩过的避坑记录看到就是赚到。1. 先想明白Spring Boot和Tomcat到底是什么关系1.1 用一个小故事理解Tomcat的本质很多人看着Tomcat这个词以为它是一个神秘的高性能服务器或者觉得它是某种Java程序运行环境。其实Tomcat的本质是一个Servlet容器加HTTP服务器。它专门负责处理网络请求和响应把浏览器或客户端发来的HTTP请求拆成Java对象调用你写好的逻辑再把结果包装成HTTP响应丢回去。举个例子你给一家餐厅打电话订餐Tomcat就是那个前台接线员。它负责接电话接收HTTP请求、记下你要什么解析请求参数、喊后厨做菜触发你的业务代码、再把做好的菜打包递给你返回HTTP响应。没有这个接线员后厨再猛也没法和外界交流。Spring Boot应用本质上是一个装满了业务代码和逻辑的后厨但它自己不能接电话它需要Tomcat这样的组件提供网络通信能力。1.2 为什么Spring Boot默认偏要选Tomcat其实Spring Boot并不只有Tomcat一个选项。Jetty、Undertow也都能用配置也很简单换掉依赖就行。但Tomcat依然是默认选择原因有三点第一Tomcat的历史和Java Web生态绑得太深了。它的Servlet容器实现一直紧跟Servlet规范Spring MVC这种建立在Servlet之上的框架和Tomcat的配合度极高基本不用额外的调试。第二Tomcat的配置能力和性能对绝大多数中小型项目足够用。线程池、连接器、虚拟主机、JSP支持包括热部署该有的都有。除非你要做超高并发的网关级应用否则Undertow在内存上省出来的那一丁点优势根本不够你折腾配置的成本。第三Tomcat的资料太全了。你遇到一个Tomcat的报错搜索一下十年前的回答都能把你捞出来。这一点在排坑的时候有多重要谁用谁知道。1.3 内嵌模式和外置部署的本质差异内嵌模式是Spring Boot最重要的设计之一。你打包一个jar包然后执行java -jar命令JVM进程起来之后Tomcat会被当作一个普通的Java类库拉进进程里由Spring Boot启动器去初始化并运行。也就是说Tomcat变成了你应用的一部分而不是存在于应用的外面。外置部署则不同你先下载并安装一个独立的Tomcat然后把自己的应用打成war包扔进Tomcat的webapps目录最后启动Tomcat这个进程。应用代码在Tomcat进程里被加载运行。这两种形态最核心的差别在于JVM进程的个数和类加载的控制。内嵌模式下Tomcat和应用在同一个进程里配置简单、部署方便一台机器跑多个服务互不干扰或者说若一个服务出问题影响面可控。外置模式下Tomcat进程是常驻的你更新一次应用要把整个webapps下的内容替换掉如果多个应用同时跑在同一Tomcat里还得考虑内存、线程池资源的竞争。2. 实操第一步环境准备与第一个内嵌应用跑起来2.1 本地开发环境怎么搭配才不踩坑先解决环境问题。你至少要准备一个JDK和一个构建工具。JDK的版本要看你选的Spring Boot版本Spring Boot 2.x可以用JDK 8也能跑在JDK 11和JDK 17上Spring Boot 3.x强制要求JDK 17以上。我建议别在这件事上纠结直接用JDK 17这是目前兼容性最好的折中方案无论Spring Boot 2.7还是3.x都能跑。构建工具我强烈建议Maven原因是Spring生态默认就是Maven文档、插件、示例代码绝大多数都是Maven格式。Gradle虽然也行但对新手来说遇到问题搜资料时会发现一半资料语法对不上会很痛苦。IDE方面很多新手被网上教程带偏总觉得必须用IDEA Ultimate才能开发Spring Boot。其实IntelliJ IDEA社区版完全够用。社区版能创建Maven项目、写Java代码、跑JUnit测试、运行Spring Boot主类自动下载依赖也没问题。唯一的遗憾是没有Spring Initializr内置向导、没有Spring相关的可视化Bean查看工具。解决办法很简单直接去start.spring.io这个网站网页版生成项目骨架下载后导入社区版开发体验几乎不差。还有一种更轻的路线是VSCode加Java扩展包。VSCode装好Extension Pack for Java之后对Spring Boot项目能提供代码补全、运行调试、Maven面板等能力。如果你机器配置不高VSCode会比IDEA流畅很多。2.2 用Spring Initializr生成项目骨架操作流程很简单浏览器打开start.spring.io选择构建工具Maven、语言Java、Spring Boot版本比如3.2.x或2.7.x然后在Dependencies那里勾选Spring Web点击Generate下载一个zip包解压后用IDE打开。这个zip包解压后是一个标准Maven工程pom.xml是核心里面已经自动引入了spring-boot-starter-parent和spring-boot-starter-web。你不需要自己搜jar包下载Maven会根据pom.xml把依赖全部拉下来。唯一要提醒的是生成项目时构建工具和Spring Boot版本要记得选对。如果你用的是JDK 8SpringBoot版本只能选2.x如果你用JDK 17选3.x或2.7.x都行但3.x和2.x在配置上有一点差异后面细说。2.3 深入看一眼spring-boot-starter-web里藏着什么新手最容易有误解的是以为starter-web是引入Spring Web框架其实它是引入了一整个Spring MVC加内嵌Tomcat的套餐。它依赖的核心组件包括spring-webmvcSpring MVC核心框架负责注解解析、请求映射、参数绑定等spring-boot-starter-json内置Jackson组件负责JSON序列化和反序列化spring-boot-starter-tomcat内嵌Tomcat的核心依赖以及tomcat-embed-core、tomcat-embed-el等具体实现包所以引入一个依赖应用就能当Web服务器跑起来的根本原因是spring-boot-starter-web把Tomcat的依赖也拉进来了。如果你不需要Web能力比如只做一个独立任务型应用不引入这个starterTomcat就不会启动这是很多人在日志里看没看到Tomcat启动信息时会困惑的点。2.4 一个可以立刻上手的Controller与启动验证新建一个类直接写代码package com.example.demo; 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 with Tomcat!; } }接着运行主类正常情况下你会在控制台看到类似这样的日志Tomcat started on port(s): 8080 (http) with context path 这行日志的意义就是内嵌Tomcat在应用进程里拉起来了监听8080端口没有额外的context path。这个时候你打开浏览器访问http://localhost:8080/hello就能看到返回的字符串。很多人觉得这没什么了不起但请记住你还没有安装任何单独的Tomcat也没有配置任何web.xml或webapps目录光靠引入一个依赖和几行代码一个完整的Web服务就跑起来了。这就是内嵌Tomcat的魔力。3. 把内嵌Tomcat调明白端口、线程池、连接器3.1 端口、IP与根路径的配置陷阱内嵌Tomcat最直接的配置在application.yml或application.properties文件里。最常见的三个是server: port: 8081 address: 0.0.0.0 servlet: context-path: /apiport代表监听端口address代表绑定的IP地址context-path代表应用的根路径。port默认是8080如果这个端口被别的程序占了可以改成任意未被占用的端口。address默认是0.0.0.0代表监听所有网卡如果你想只允许本机访问可以改成127.0.0.1。context-path这个配置非常容易踩坑。很多人配了之后访问不到接口就是因为不理解为啥加了context-path之后原来的/hello变成了/api/hello。它的作用是给你的应用加一个统一的前缀可以避免和其他应用冲突。但要注意如果你在Controller里定义的是GetMapping(/hello)实际访问地址必须包含前缀。另外还有一个容易忽略的点如果context-path设置了那么Spring Boot Actuator监控端点的访问路径也会跟着带上前缀。比如你之前习惯访问/actuator/health加了context-path: /api后要访问/api/actuator/health才行。3.2 线程池参数到底怎么调才合理Tomcat内部有一个线程池来处理请求它的行为和操作系统里处理外卖订单的派送团队很像。每个请求进来会占用一个线程线程处理完就归还给线程池。核心参数有三个server: tomcat: threads: max: 200 min-spare: 10 accept-count: 100max最大工作线程数。超过这个数Tomcat不会立刻拒绝请求而是把新请求放到等待队列里。accept-count等待队列的容量。当工作线程全满时新请求会进入队列等待如果队列也满了Tomcat才开始拒绝连接。min-spare最小空闲线程数范围是0到max。Tomcat启动时就会预创建这么多线程放在池里备用目的是减少请求来临时创建线程的延迟。我给一个具体的类比max相当于店里最多能同时接待的顾客数accept-count相当于大厅里的排队座位min-spare相当于提前安排好的空闲服务员。排队座位坐满了新来的客人才会被礼貌地请走。调参建议初期别乱改默认值对绝大多数场景够用。如果你做的是接口响应极快但并发量高的服务可以适当提高max到400~500如果你做的是慢接口、长连接业务max不宜过高否则大量线程都阻塞在等待响应上CPU上下文切换消耗很大反而拖垮性能。3.3 连接数配置别把最大连接数当做万能药除线程池外连接器层面的配置也要关注server: tomcat: max-connections: 10000 connection-timeout: 20000max-connections是Tomcat在某个时刻能接收并处理的TCP连接最大数量包括正在处理的请求和等待中的连接。它和线程数的关系要分清线程池处理的是应用层的业务调用连接是网络层面的连接。一个连接对应一个请求但这个请求处理期间会占用一个工作线程。所以max-connections要大于线程池的max否则连接还没到应用层就被卡住。connection-timeout是连接超时时间单位是毫秒。它决定了一个连接建立后多久没发送请求就断掉。这个值不宜太短否则浏览器端偶尔忙一下再重新请求会频繁断连也不宜太长否则大量空闲连接占用资源。3.4 开启访问日志的方法排查问题的时候Tomcat的访问日志极其有用。它记录了每个请求的来源IP、时间、HTTP方法、请求路径、状态码和响应耗时。开启方式很简单server: tomcat: accesslog: enabled: true directory: /var/log/tomcat pattern: %h %l %u %t %r %s %b %Dpattern里面的%h是远程主机名%l是逻辑用户名%u是认证用户名%t是请求时间%r是请求行%s是状态码%b是响应字节数%D是处理耗时毫秒数。强烈建议把%D加进去它对于定位慢接口非常直接。你可以在参数大小和自定义传输的任何维度上发现异常这一点比在业务代码里加计时器省事得多。3.5 用代码实现更复杂的定制如果配置文件的语法不够表达需求你可以实现WebServerFactoryCustomizer接口在代码里操作Tomcat。import org.springframework.boot.web.embedded.tomcat.TomcatServletWebServerFactory; import org.springframework.boot.web.server.WebServerFactoryCustomizer; import org.springframework.stereotype.Component; Component public class TomcatCustomizer implements WebServerFactoryCustomizerTomcatServletWebServerFactory { Override public void customize(TomcatServletWebServerFactory factory) { factory.setPort(9090); factory.setContextPath(/app); } }这个方式适合动态设置端口比如从配置中心拉取端口值、动态调整未来连接器数量等场景。不过注意设置端口通常还是不推荐写死在代码里的除非端口来自环境变量或者外部配置中心否则直接用配置文件更直观。4. JVM参数调整让内嵌Tomcat跑出更稳的成绩4.1 为什么Tomcat性能需要JVM调优支撑Tomcat本身是一个Java程序它运行在JVM里。线程池、连接池、对象分配、类加载这些全部依赖于JVM的内存管理和垃圾回收。默认的JVM参数面向的是一般场景对Tomcat这种偏网络IO、对象创建频繁的应用并不一定友好。最直接的例子默认堆内存很小物理内存的四分之一上限可能低于你预期压测时稍微来点流量GC频率就会飙升响应时间瞬间变差。JVM调优不是玄学它解决的是内存给够不够、GC策略合不合理、老年代垃圾回收会不会经常卡顿的问题。4.2 设置JVM参数的三条实战路径最常见的路径是启动jar包时直接在命令行传参java -Xms512m -Xmx1024m -XX:MetaspaceSize128m -XX:MaxMetaspaceSize256m -jar your-app.jar如果是在IDE里开发调试以IDEA为例你可以在运行配置里找到VM options那一栏填上相同的参数。VSCode里则在launch.json或Maven插件配置里设置。部署到Linux服务器时通常写在一个启动脚本里把JVM参数、jar包路径、日志输出统一管理。还有一条路径是设置环境变量JAVA_TOOL_OPTIONS或JAVA_OPTS让JVM启动时自动读取。不过这只在容器或某些启动脚本场景下推荐本地调试时可读性不如直接在IDEA里配。4.3 一套实测下来比较稳的参数组合我自己的经验是对于大多数基于Spring Boot和Tomcat的服务下面这套参数可以作为起点-Xms512m -Xmx1024m -XX:MetaspaceSize128m -XX:MaxMetaspaceSize256m -XX:UseG1GC -XX:MaxGCPauseMillis200 -XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/data/logs/dump-Xms和-Xmx分别设定堆内存的初始值和最大值。建议两者设为相等的值避免运行期动态扩容带来的内存抖动和性能损失。MetaspaceSize是存放类元数据的区域Spring Boot应用类很多默认值太小容易频繁触发元空间Full GC。G1GC是JDK 9之后的默认垃圾收集器它的核心优势是设置了MaxGCPauseMillis来尽量控制停顿时间。HeapDumpOnOutOfMemoryError用来在OOM的时候打一份堆转储文件这个文件是事后排查内存泄漏的关键线索。实测下来一个重要感受堆内存别贪大。很多新手直接把Xmx设成8G以为大就一定好结果GC停顿变长反而让接口响应变得不稳定。内存大小要根据业务情况算先按默认跑几天压测观察应用实际占用峰值再合理调整。盲目给大内存等于给自己挖坑。5. 部署形态内嵌jar、外置war和前后端分离的取舍5.1 把应用打成war包部署到外置Tomcat的完整步骤虽然Spring Boot默认推荐内嵌模式但确实有场景必须外置Tomcat公司运维统一要求把所有Java应用装到一个Tomcat里管理或者你的项目是旧系统改造必须和其他传统war包共存。打war包的步骤并不复杂第一步把pom.xml里的packaging改成warpackagingwar/packaging第二步引入spring-boot-starter-tomcat并设置provided作用域dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-tomcat/artifactId scopeprovided/scope /dependency这样做的意思是打war包时不把Tomcat的jar打进去因为它由外置Tomcat容器来提供。如果这里不设置scopewar包里的lib目录会带一份Tomcat embed jar和容器自身自带的Tomcat冲突启动时会报各种奇怪的ClassNotFound异常。第三步修改主类继承SpringBootServletInitializerSpringBootApplication public class DemoApplication extends SpringBootServletInitializer { Override protected SpringApplicationBuilder configure(SpringApplicationBuilder builder) { return builder.sources(DemoApplication.class); } public static void main(String[] args) { SpringApplication.run(DemoApplication.class, args); } }第四步执行mvn clean package把生成的war包复制到Tomcat的webapps目录启动Tomcat即可。5.2 内嵌与外置的详细对比我把两种方式的区别整理成一张表格方便你决策维度内嵌jar外置war部署方式java -jar 一条命令拷到webapps启动Tomcat环境依赖只需要JDK需要单独安装Tomcat多应用隔离每个服务独立进程共享同一Tomcat进程端口管理每个服务独立端口所有应用share同一端口context path升级维护替换jar重启即可替换war可能需要重启Tomcat调试便利性本地启动异常容易定位启动慢、日志多出容器层对外提供API的服务我强烈推荐内嵌jar原因是隔离性好升级灵活。只有企业内部老旧系统整合需要才考虑war。有一条经验值得补充如果你用外置Tomcat部署多个war而且这些war都有相同的第三方依赖你得注意依赖冲突问题可能这个war里的A包版本覆盖了那个war里需要的B包版本。Tomcat的共享类加载机制在这里能帮一些忙但总体来说是和具体应用强耦合的领域能不用外置就尽量别用。5.3 前后端分离项目部署时的正确认知前后端分离部署和Tomcat本身关系不大不过很多人因为没搞懂而被误导。前端项目一般是Nginx托管静态页面然后通过反向代理把/api开头的请求转发给后端接口。后端就是用Spring Boot内嵌Tomcat跑一个纯API服务。Nginx配置大概长这样server { listen 80; server_name example.com; location / { root /var/www/frontend; index index.html; } location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }这种模式里Tomcat并不直接处理静态资源只处理动态接口。所以如果你只做API后端完全没必要给Spring Boot静态资源路径配太多东西。6. 避坑指南现场问题与排查实录6.1 端口被占用的三层排查法这是新手提问率最高的报错之一Port 8080 was already in use.处理思路按这个顺序来先找到是什么占了端口。Windows下用netstat -ano | findstr 8080Linux或macOS用lsof -i:8080。拿到PID后在任务管理器或taskkill /F /PID 进程号里杀掉进程。再确认是不是自己其他Java项目占的。如果是要么换个端口要么把那个项目关掉。如果是系统服务比如Windows的HTTP服务默认占用80端口、SQL Server报表服务占用一些固定端口那就要考虑换一个自己的服务端口。最后还要检查一种隐蔽情况server.port: 0。这个配置的意思是让Tomcat随机分配一个可用端口。如果你配置了0日志里显示的端口每次启动都不同这种随机端口适合测试环境但绝不能用在生产环境否则客户端没法稳定连接。6.2 源服务器未能找到目标资源的表示到底怎么治这个报错非常典型网上最常见的英文原文是HTTP Status 404 – Not Found, The origin server did not find a current representation for the target resource。它出现的原因十有八九是你在浏览器访问的URL和应用实际映射的URL不一致。排查步骤很简单先看Controller的映射路径。比如你写成GetMapping(/user)访问时就应该是http://localhost:8080/user少一个斜杠都不行。再看是否有context-path后面记得带上前缀。第三看有没有开启classpath扫描限制如果你的Application主类和Controller不在同一个包或子包下Spring可能没有把Controller注册进去也会导致404。最后我遇到过一种更坑的情况IDEA里忘了重新编译改了代码但运行的是旧class文件重启都没有效。这种情况清一下target目录重试就好。6.3 Tomcat闪退的日志定位方法很多人在Windows上下载了独立Tomcat双击startup.bat结果窗口一闪就没了。这不是Spring Boot内嵌模式的问题而是外置Tomcat常遇到的。直接双击启动时如果有错误cmd窗口关闭就丢弃了输出你什么都看不到。解决办法是用命令窗口手动定位先在cmd里切到Tomcat的bin目录执行startup.bat或者直接前台运行catalina.bat run这次输出的错误会留在窗口里。常见原因有三个JAVA_HOME或JRE_HOME没设置导致Tomcat找不到Java环境端口8080被占用日志里会报Address already in use内存设置不正确比如catalina.bat里改了-Xmx和-Xms后启动失败日志文件默认在logs目录下重点是catalina.out或系统日期命名的log文件。6.4 WebSocket集成时yml配置的常见坑Spring Boot集成WebSocket时最别扭的是允许跨域那些配置。核心配置在Spring Security或普通拦截器层面yml里其实没有多少WebSocket专属选项但很多人误以为要在yml里配置什么websocket.allowed-origins之类的字段。实际上Spring Boot的WebSocket配置更多依赖代码。一个典型的例子如果你想允许跨域WebSocket连接通常是在注册处理器时设置setAllowedOriginPatterns(*)同时注意端口和context-path是否正确。如果你前后端分离前端WebSocket地址写的是ws://localhost:8080/ws而后端context-path是/api那实际地址就是ws://localhost:8080/api/ws写错地址只会连接失败。yml配置里真正需要关注的是应用的基础信息端口、路径是否前后端一致以及使用消息代理时像STOMP那种协议所需的broker配置。6.5 双亲委派机制为什么Tomcat要打破它这是一个被提问率很高的进阶问题用大白话说就是JVM加载类的时候会先让父类加载器去尝试加载父类加载不了才轮到自己。这种机制保证核心Java类不会被篡改。但Tomcat偏偏要打破这个机制因为它要加载多个web应用每个应用可能有不同版本的同一个类库。Tomcat给每个Web应用创建了一个独立的WebAppClassLoader它没有先去问父加载器而是先尝试自己加载应用里WEB-INF/classes和WEB-INF/lib下的类找不到时才委托给父加载器。这样就解决了多个war包里第三方库版本冲突的问题。在Spring Boot内嵌模式下因为通常一个进程只有一个应用Tomcat这套复杂机制用得不多但你在排错时如果看到ClassNotFoundException: org.springframework.之类的报错往往是依赖没导全或打包时被排除了依赖而不是场景问题。6.6 Bean注入控制写代码时最容易犯的低级错误Spring Boot用的单例Bean生命周期和Tomcat没有直接关系但属于新手高频问题。最典型的坑是Autowired注入的对象为null并伴随NullPointerException。根本原因通常是你要注入的Bean没有被Spring管理。常见诱因有三个你实例化了某个类但忘了加Service、Component等注解你在new出来的类里用AutowiredSpring根本不会注入两个Bean之间存在循环依赖Spring能解决但有损耗解决不了就直接报BeanCurrentlyInCreationException排查思路很清晰看注入点所在类是否被Spring容器扫描到扫描包范围是否正确再看注入Bean上有没有标注注解。如果是要注入配置属性记得使用ConfigurationProperties或Value并确保类能被Spring管理。6.7 静态资源404和war包上传限制问题开发阶段需要注意一个细节Spring Boot内嵌Tomcat默认把classpath下的static、public、resources目录当作静态资源根目录。如果你放了静态HTML或图片但访问404检查一下你是不是把文件放到了src/main/java下面或者路径里带上了classes前缀。正确路径是src/main/resources/static/index.html对应访问http://localhost:8080/index.html。war包上传限制IP的问题通常说的不是Tomcat配置而是部署运维层面加了白名单。解决办法没法子只能联系运维放行你的IP或者改用内网部署。这个问题的本质是公司安全策略不是代码bug。6.8 常见问题速查表现象排查方向解决思路端口被占用netstat/lsof查进程换端口或杀进程404Controller路径、context-path、包扫描逐一核对映射与启动类位置外置Tomcat启动闪退看logs/catalina.out设置JAVA_HOME、检查端口占用WebSocket连不上地址、端口、context-path、跨域统一前后端地址设置AllowedOriginPatterns注入为nullBean是否被Spring管理加注解或调整扫描范围静态资源404文件位置和路径放到src/main/resources/static下打war包后启动报错是否引入starter-tomcat provided检查pom.xml依赖scopeJVM内存溢出看HeapDump报表调大Xmx并考虑优化业务7. Spring Boot 2.3.x到3.x的演进版本升级踩坑记录7.1 关键版本差异概览很多项目现在还跑在Spring Boot 2.3.x、2.6.x上而新项目已经用了3.x。搞清楚这两个大版本的区别对你的技术选型和升级都很重要。Spring Boot 2.x系列基于Spring Framework 5.x支持JDK 8到17javax命名空间javax.servlet、javax.persistence等。Spring Boot 3.x则基于Spring Framework 6.x最低要求JDK 17命名空间全面升级为jakartajakarta.servlet等这是一个巨大的包名变化。如果你要在JDK 25那个最新版本上跑Spring Boot尤其是老项目大概率会踩到兼容性问题。老版本框架不支持太新的JDK行为变化所以JDK版本更新时要么升级Spring Boot版本要么放弃。7.2 升级到Spring Boot 3.x要注意的坑升级最痛苦的是包名迁移。几乎所有的javax.都要变成jakarta.。尤其是servlet相关的代码例如import javax.servlet.http.HttpServletRequest要改成import jakarta.servlet.http.HttpServletRequest。另一个坑是starter的路径变化。Spring Boot 3.x里很多自动配置类的类名路径变了如果你自定义配置里写死了旧的类名启动时会直接NoClassDefFoundError。Spring Boot 3对三方工具兼容要求也高。比如某些监控组件、连接池、分布式组件没有升级到支持jakarta的版本同样无法使用。如果你在项目里用了大量自定义starter升级前先确认这些依赖是否有对应版本。建议升级时step by step先在本地把Spring Boot版本升级到最新的3.2.x编译一次项目把所有的编译错误解决完再运行集成测试。期间把pom.xml里的parent版本改掉然后反复执行mvn clean test。不要想着一次性大版本跨越后顺便换掉其他框架升级的复杂度会急剧上升。8. 事件之后再聊几句个人使用的几个小习惯讲到这儿核心内容基本覆盖了。最后分享几个我自己的使用习惯不一定适合所有人但实测下来确实省了很多排查时间。第一个习惯新项目一定在启动脚本里加上打印JVM参数和生效配置的功能。最简单的做法是启动命令中加上--debug参数Spring Boot会打印自动配置的匹配决策你能看到哪些Tomcat配置被应用、哪些被忽略。第二个习惯把Tomcat访问日志永远打开。哪怕在本地开发环境也开着只是目录建在target/logs下。这样一旦出现HTTP 500、404、请求很慢的问题先看访问日志基本能缩小90%的定位范围。第三个习惯不要把端口和线程池配置散落在多个配置文件。统一集中到application.yml的server节点下备注清楚为什么要调这个值。很多项目过半年后连当初自己写的参数含义都忘了好的注释比改代码更重要。第四个习惯上线前压测至少跑一次简单并发测试比如用wrk、Jmeter或者ab。不用跑很复杂的场景就试一试用默认线程池能支撑多少并发。这个数据记录了之后你调参心里就有底不会盲目改配置。这个项目从零搭建到现在走了不少弯路代价不算大但每一步都是我实测后沉淀下来的。希望这份整理能帮你少踩几次坑。如果照着操作还有问题多半是环境差异导致的建议把报错日志完整贴给搜索引擎比瞎猜有效一百倍。