企业官网建设流程全解析

1. 项目概述：为什么SpringBoot项目还要用Tomcat启动？

“使用tomcat启动SpringBoot项目”这个标题乍看有点反直觉——毕竟SpringBoot官方文档里反复强调“内嵌Tomcat，开箱即用”，很多新手甚至以为SpringBoot和Tomcat是互斥关系。但现实项目中，我经手过的20多个中大型系统部署案例里，有14个最终都回归了外置Tomcat部署模式。这不是倒退，而是工程落地时绕不开的权衡结果。

核心关键词就三个：SpringBoot、Tomcat、外置部署。它解决的不是“能不能跑”的问题，而是“在生产环境里怎么跑得稳、改得快、查得清、扩得顺”的问题。适合三类人重点参考：一是正在从传统SSM架构迁移的老项目组，二是需要与遗留JavaEE系统共存的集成场景，三是对JVM参数调优、线程池监控、类加载隔离有强管控需求的运维/中间件团队。

举个真实例子：某高校教务系统的SpringBoot改造项目，前端用Vue打包成静态资源，后端用SpringBoot重构业务逻辑。开发阶段用mvn spring-boot:run跑得飞快，但上线后发现两个硬伤：第一，运维要求所有Java应用必须统一通过公司自研的容器管理平台启停，该平台只识别标准WAR包和catalina.sh生命周期；第二，系统需对接老OA系统的EJB服务，而EJB客户端依赖特定版本的jboss-client.jar，放在lib/ext下才能被全局类加载器识别——内嵌Tomcat的LaunchedURLClassLoader根本加载不到。这两个问题，不切到外置Tomcat，根本无解。

所以这不是技术炫技，而是把SpringBoot从“玩具级开发体验”推向“工业级交付能力”的必经之路。它背后牵扯的是类加载机制、Servlet容器生命周期、WAR包构建规范、JVM内存模型等一整套Java Web底层逻辑。接下来我会拆解清楚：为什么选Tomcat而不是Jetty或Undertow？怎么改代码才能兼容外置容器？打包时哪些坑会让部署直接失败？以及最关键的——线上出问题时，如何快速定位是SpringBoot层还是Tomcat层的故障？

2. 整体设计思路与方案选型逻辑

2.1 为什么不是“放弃SpringBoot”，而是“让SpringBoot适配Tomcat”？

很多人看到“用Tomcat启动SpringBoot”，第一反应是“那还用SpringBoot干啥？直接写Servlet不更简单？” 这是个典型误区。SpringBoot的价值从来不在“有没有内嵌容器”，而在于它封装了自动配置（Auto-Configuration）、起步依赖（Starter）、条件化Bean注册（@Conditional）这三大核心能力。这些能力在外置Tomcat中完全保留，且能带来更大优势：

• 配置复用性：application.yml里的server.port、spring.datasource等配置，在外置Tomcat中依然生效，只是server.port会被忽略（由Tomcat的server.xml决定），而数据库连接池、Redis客户端等配置照常初始化；
• 生态无缝衔接：Actuator健康检查端点、Prometheus指标暴露、Spring Security的Filter链、Spring Cloud Gateway的路由规则——所有基于Spring Boot Actuator和Spring MVC的扩展，无需任何修改即可运行；
• 开发-测试-生产一致性：开发用内嵌Tomcat快速迭代，测试环境用Docker+外置Tomcat模拟生产，避免“在我机器上能跑”的经典陷阱。

真正要放弃的，只是SpringApplication.run()这行启动代码，以及对EmbeddedServletContainerCustomizer的依赖。其他95%的SpringBoot能力，原封不动。

2.2 Tomcat版本选择：不是越新越好，而是匹配JDK和SpringBoot版本

选错Tomcat版本是部署失败的第一大原因。我整理了近3年主流组合的兼容矩阵，实测验证过：

提示：千万别用Tomcat 10+去跑SpringBoot 2.x！因为Tomcat 10将javax.servlet.*包名改为jakarta.servlet.*，而SpringBoot 2.x的源码里全是javax引用，编译期就报错。曾有个团队在预发环境卡了两天，最后发现是运维同事图省事，直接下载了最新版Tomcat 10.1，结果整个WAR包启动时报NoClassDefFoundError: javax/servlet/ServletContext。

2.3 WAR包 vs JAR包：为什么必须打WAR？

SpringBoot默认打包为可执行JAR（fat jar），其结构是：

myapp.jar ├── BOOT-INF/classes/ ← 自己的class ├── BOOT-INF/lib/ ← 所有依赖jar（包括spring-webmvc-5.3.31.jar） └── org/springframework/boot/loader/ ← 启动类加载器

而外置Tomcat要求标准WAR包结构：

myapp.war ├── WEB-INF/classes/ ← 自己的class ├── WEB-INF/lib/ ← 依赖jar（但不能包含servlet-api.jar等容器提供的jar） ├── WEB-INF/web.xml ← 可选，SpringBoot项目通常不需要 └── static/, templates/ ← 静态资源和模板

关键差异在于：WAR包的类加载器层级是双亲委派的，而JAR包的LaunchedURLClassLoader是反双亲委派的。这意味着在WAR包中，javax.servlet.http.HttpServlet由Tomcat的CommonClassLoader提供，你的代码里引用的HttpServlet自然能匹配；但在JAR包中，如果依赖里混入了不同版本的servlet-api.jar，就会出现LinkageError。

所以第一步必须改pom.xml，把打包方式从jar切到war，并排除掉Tomcat内嵌依赖——这是整个方案的地基，地基不牢，后面全塌。

3. 核心细节解析与实操要点

3.1 Maven配置：三处关键修改，缺一不可

这是最容易出错的环节。我见过太多人只改了<packaging>，忘了排除内嵌Tomcat，结果部署时报java.lang.IllegalArgumentException: LoggerFactory is not a Logback LoggerContext but Logback is on the classpath——本质是Logback和Tomcat自带的java.util.logging冲突。

第一步：修改打包类型

<packaging>war</packaging>

注意：必须放在<project>根节点下，且不能和<scope>provided</scope>混用。

第二步：排除内嵌Tomcat依赖（最易遗漏！）

<dependencies> <!-- SpringBoot Web Starter --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> <!-- 关键：将内嵌Tomcat设为provided，告诉Maven“运行时由容器提供” --> <exclusions> <exclusion> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-tomcat</artifactId> </exclusion> </exclusions> </dependency> <!-- 显式声明Tomcat Servlet API（provided，不打入WAR） --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-tomcat</artifactId> <scope>provided</scope> </dependency> </dependencies>

注意：spring-boot-starter-tomcat的<scope>provided</scope>必须显式声明。如果不写，Maven会把它当作compile范围，最终打入WEB-INF/lib/，导致和Tomcat自带的servlet-api.jar冲突。我踩过这个坑：本地IDE能启动，但部署到测试Tomcat时，ServletContext初始化失败，日志里满屏ClassNotFoundException。

第三步：添加Servlet初始化入口（SpringBoot 2.4+必需）

SpringBoot 2.4开始废弃SpringBootServletInitializer的configure()方法，改用SpringApplication的setWebApplicationType()。但外置Tomcat仍需一个ServletContainerInitializer来触发Spring上下文加载。因此必须创建一个继承类：

// src/main/java/com/example/demo/ServletInitializer.java @SpringBootApplication public class ServletInitializer extends SpringBootServletInitializer { @Override protected SpringApplicationBuilder configure(SpringApplicationBuilder application) { // 这行代码告诉SpringBoot：别自己启动内嵌容器，等Tomcat来调用 return application.sources(DemoApplication.class); } public static void main(String[] args) { SpringApplication.run(DemoApplication.class, args); } }

这个类有两个作用：一是重写configure()方法，让SpringBoot知道“我在WAR包里”；二是保留main()方法，保证开发时仍可用java -jar启动（虽然不推荐，但方便调试）。

3.2 application.yml配置：哪些参数失效？哪些必须调整？

外置Tomcat接管了HTTP层，所以server.*前缀的配置大部分失效，但并非全部。我整理了一份实测有效的配置清单：

实操心得：不要试图在application.yml里配置Tomcat线程池！比如server.tomcat.threads.max=200，这行配置在外置模式下完全被忽略。正确做法是编辑$TOMCAT_HOME/conf/server.xml：

<Connector port="8080" protocol="HTTP/1.1" maxThreads="200" minSpareThreads="10" acceptCount="100" connectionTimeout="20000" redirectPort="8443" />

我曾帮一个电商项目调优，他们把maxThreads设成1000，结果Tomcat OOM崩溃——因为每个线程默认占1MB栈空间，1000线程就是1GB，远超JVM堆外内存。最后调到200，配合acceptCount=100（等待队列），并发承载能力反而提升3倍。

3.3 WAR包构建与部署验证：三步确认法

打完WAR包不能直接扔进webapps目录就完事，必须验证三个关键点：

第一步：检查WAR包结构是否合规

解压WAR包，确认以下目录存在且内容合理：

• WEB-INF/classes/：必须包含你自己的com/example/demo/DemoApplication.class和application.yml
• WEB-INF/lib/：不能出现servlet-api.jar、jsp-api.jar、tomcat-*.jar，但应该有spring-web-5.3.31.jar、mybatis-spring-2.2.0.jar等业务依赖
• WEB-INF/lib-provided/：不应该存在，SpringBoot不会生成这个目录（那是Maven插件maven-dependency-plugin的产物）

用命令快速验证：

# 查看是否有禁止的jar unzip -l myapp.war | grep -i "servlet\|jsp\|tomcat" # 正确输出应为空；如果出现类似"WEB-INF/lib/tomcat-embed-core-9.0.83.jar"，说明exclusion没生效 # 检查主类是否存在 unzip -l myapp.war | grep "DemoApplication.class" # 应返回"WEB-INF/classes/com/example/demo/DemoApplication.class"

第二步：部署后检查Tomcat日志

启动Tomcat，观察$TOMCAT_HOME/logs/catalina.out，关键成功标志有三行：

INFO o.s.b.w.s.c.ServletWebServerFactoryCustomizer - Server properties: [server.port=0] # 注意port=0，表示已禁用内嵌 INFO o.s.b.w.s.c.ServletWebServerFactoryCustomizer - Tomcat servlet web server customizing... INFO o.s.b.w.s.c.ServletWebServerFactoryCustomizer - Tomcat started on port(s): 8080 (http) with context path '/myapp'

最后一行中的context path '/myapp'，就是你的应用上下文路径，由WAR包名决定（myapp.war→/myapp）。

第三步：验证Actuator端点是否可用

访问http://localhost:8080/myapp/actuator/health，应返回JSON：

{"status":"UP","components":{"diskSpace":{"status":"UP","details":{"total":500000000000,"free":200000000000,"threshold":10485760}}}}

如果返回404，说明SpringBoot上下文没加载成功；如果返回500且日志里有NoSuchBeanDefinitionException，大概率是ServletInitializer类没被Tomcat扫描到（检查类路径和@SpringBootApplication位置）。

4. 实操过程与核心环节实现

4.1 从零开始：一个可运行的最小化示例

我们用最简步骤，构建一个能在Tomcat 9.0.83上运行的SpringBoot WAR包。全程基于SpringBoot 2.7.18（LTS版本），JDK 8u292。

步骤1：初始化项目（用Spring Initializr）

• 访问 https://start.spring.io/
• 选择：Project: Maven, Language: Java, Spring Boot: 2.7.18
• Dependencies: Spring Web, Spring Boot DevTools, Lombok（可选）
• Generate：下载demo.zip，解压

步骤2：修改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 http://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>demo</artifactId> <version>0.0.1-SNAPSHOT</version> <packaging>war</packaging> <!-- 第一处修改 --> <properties> <java.version>1.8</java.version> </properties> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> <exclusions> <!-- 第二处修改：排除内嵌Tomcat --> <exclusion> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-tomcat</artifactId> </exclusion> </exclusions> </dependency> <!-- 第三处修改：显式声明provided Tomcat --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-tomcat</artifactId> <scope>provided</scope> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-devtools</artifactId> <scope>runtime</scope> <optional>true</optional> </dependency> </dependencies> <build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> </plugin> </plugins> </build> </project>

步骤3：创建ServletInitializer类

// src/main/java/com/example/demo/ServletInitializer.java package com.example.demo; import org.springframework.boot.builder.SpringApplicationBuilder; import org.springframework.boot.web.servlet.support.SpringBootServletInitializer; public class ServletInitializer extends SpringBootServletInitializer { @Override protected SpringApplicationBuilder configure(SpringApplicationBuilder application) { return application.sources(DemoApplication.class); } }

步骤4：修改主启动类，继承ServletInitializer

// src/main/java/com/example/demo/DemoApplication.java package com.example.demo; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; // 关键：让主类继承ServletInitializer，否则Tomcat找不到入口 @SpringBootApplication public class DemoApplication extends ServletInitializer { // 继承这里！ public static void main(String[] args) { SpringApplication.run(DemoApplication.class, args); } }

步骤5：编写一个测试Controller

// src/main/java/com/example/demo/HelloController.java 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 from Tomcat-deployed SpringBoot!"; } }

步骤6：构建WAR包

# 在项目根目录执行 mvn clean package -DskipTests # 输出：target/demo-0.0.1-SNAPSHOT.war

步骤7：部署到Tomcat 9.0.83

# 下载Tomcat 9.0.83（官网tar.gz包） wget https://dlcdn.apache.org/tomcat/tomcat-9/v9.0.83/bin/apache-tomcat-9.0.83.tar.gz tar -xzf apache-tomcat-9.0.83.tar.gz # 复制WAR包 cp target/demo-0.0.1-SNAPSHOT.war apache-tomcat-9.0.83/webapps/myapp.war # 启动 apache-tomcat-9.0.83/bin/startup.sh

步骤8：验证访问

浏览器打开http://localhost:8080/myapp/hello，返回文本即成功。

实测记录：整个流程耗时12分钟（含下载Tomcat）。其中最耗时的是第一次构建WAR包（Maven下载依赖），后续修改代码只需mvn compile+cp，30秒内完成热替换。比Docker重启快一个数量级。

4.2 生产级配置：JVM参数、日志分离、健康检查

开发能跑不等于生产可用。以下是我在某金融系统上线前强制要求的五项配置：

JVM参数调优（写入$TOMCAT_HOME/bin/setenv.sh）

#!/bin/sh # Tomcat启动时自动加载此文件 export JAVA_OPTS="-server \ -Xms2g -Xmx2g \ # 堆内存固定2G，避免动态扩容GC停顿 -XX:MetaspaceSize=256m \ # 元空间初始大小 -XX:+UseG1GC \ # 强制G1垃圾收集器 -XX:MaxGCPauseMillis=200 \ # GC最大停顿200ms -Dfile.encoding=UTF-8 \ # 统一文件编码 -Dsun.jnu.encoding=UTF-8"

注意：-Xms和-Xmx必须相等！否则在高并发下，堆内存扩容会触发Full GC，导致请求超时。我亲眼见过一个支付接口因-Xms1g -Xmx4g，在流量峰值时每分钟触发3次Full GC，TP99从200ms飙升到8秒。

日志分离：避免catalina.out爆炸

SpringBoot默认把所有日志（包括Tomcat自身日志）都打到catalina.out，线上排查时根本分不清是应用日志还是容器日志。解决方案是用Logback分离：

在src/main/resources/logback-spring.xml中：

<?xml version="1.0" encoding="UTF-8"?> <configuration> <!-- 定义应用日志文件 --> <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>logs/myapp.log</file> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <fileNamePattern>logs/myapp.%d{yyyy-MM-dd}.%i.log</fileNamePattern> <timeBasedFileNamingAndTriggeringPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP"> <maxFileSize>100MB</maxFileSize> </timeBasedFileNamingAndTriggeringPolicy> </rollingPolicy> <encoder> <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern> </encoder> </appender> <!-- 只让应用日志走FILE，Tomcat日志仍走catalina.out --> <root level="INFO"> <appender-ref ref="FILE"/> </root> </configuration>

这样logs/myapp.log只记录SpringBoot应用日志，catalina.out只记录Tomcat启动、线程池告警等容器级日志，排查效率提升5倍。

健康检查端点加固

默认的/actuator/health只返回UP/DOWN，无法满足生产监控需求。添加详细健康指标：

# application.yml management: endpoint: health: show-details: when_authorized # 开发时可看详情，生产需鉴权 endpoints: web: exposure: include: health,info,metrics,prometheus,loggers endpoint: prometheus: scrape-interval: 15s

然后在pom.xml中加入：

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency> <dependency> <groupId>io.micrometer</groupId> <artifactId>micrometer-registry-prometheus</artifactId> </dependency>

部署后访问http://localhost:8080/myapp/actuator/prometheus，即可被Prometheus抓取JVM内存、HTTP请求数、数据库连接池等200+指标。

5. 常见问题与排查技巧实录

5.1 WAR包部署后404：八成是这三个原因

这是最高频问题。按优先级排序排查：

实操心得：遇到404先别急着改代码，用curl -v看响应头。如果返回HTTP/1.1 404 Not Found且Content-Type: text/html，说明是Tomcat层面的404（应用根本没起来）；如果返回HTTP/1.1 404但Content-Type: application/vnd.spring-boot.actuator.v3+json，说明SpringBoot起来了，但MVC没找到Handler（Controller问题）。

5.2 启动卡住或报ClassNotFoundException：类加载冲突诊断表

独家技巧：用Tomcat的verbose:class参数看类加载过程。在setenv.sh中加：

export JAVA_OPTS="$JAVA_OPTS -verbose:class"

启动后搜索[Loaded org.springframework.boot.web.servlet.support.SpringBootServletInitializer，如果看到两次加载（一次来自WEB-INF/lib/，一次来自$TOMCAT_HOME/lib/），就坐实了类加载冲突。

5.3 性能问题：为什么外置Tomcat比内嵌慢？

很多团队反馈“切到外置Tomcat后，接口RT从50ms涨到200ms”。这不是Tomcat的问题，而是SpringBoot的自动配置在两种模式下行为不同。关键差异点：

实测数据：某新闻API服务，启用Tomcat原生GZIP后，平均响应体从120KB降到35KB，QPS从1200提升到2100；关闭SpringBoot静态处理后，首页加载时间从320ms降到85ms。

5.4 热部署难题：如何实现不重启Tomcat更新代码？

外置Tomcat的热部署一直被诟病。其实有三种可靠方案，按稳定性排序：

1. WAR包增量更新（推荐）
   利用Tomcat的reloadable特性：在server.xml中为Context配置：

   <Context docBase="/path/to/myapp.war" reloadable="true" />

   然后每次mvn clean package后，用rsync同步WAR包：

   rsync -avz target/myapp.war $TOMCAT_HOME/webapps/

   Tomcat检测到WAR包修改，自动解压并重启应用。实测平均重启时间2.3秒，比整机重启快10倍。

2. JRebel商业方案
   付费但最稳定，支持类、方法、注解、配置文件的实时热替换，无需重启。某保险核心系统用JRebel后，开发联调效率提升70%，但年授权费约2万元/人。

3. Spring Loaded（已淘汰，仅作历史参考）
   Spring官方已停止维护，不建议新项目使用。替代品是spring-boot-devtools的restart功能，但它只适用于内嵌模式。

最后分享一个小技巧：在application-dev.yml中加：

spring: devtools: restart: additional-paths: src/main/java exclude: "**/*.class"

这样IDE保存Java文件后，devtools会触发类重载，比Tomcat的reloadable更快（毫秒级），且不影响生产配置。

6. 进阶场景：集群部署与灰度发布实践

6.1 Nginx+Tomcat集群：Session共享的三种方案对比

单台Tomcat无法承载高并发，必须集群。但SpringBoot默认的HttpSession是内存级的，用户请求落到不同节点会丢失登录态。解决方案有三：

我主导的某政务服务平台选了Redis方案，具体配置如下：

<!-- pom.xml --> <dependency> <groupId>org.springframework.session</groupId> <artifactId>spring-session-data-redis</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-redis</artifactId> </dependency>

# application.yml spring: redis: host: 10.0.1.100 port: 6379 password: ${REDIS_PASSWORD:} session: store-type: redis timeout: 1800 # 30分钟

注意：必须在主类上加@EnableSpringHttpSession，否则Session不走Redis。曾有个项目漏了这行，压测时发现所有节点Session独立，用户频繁登出，排查了两天才发现注解缺失。

6.2 灰度发布：用Tomcat的<Context>实现流量切分

不用引入Spring Cloud Gateway，纯Tomcat就能做灰度。原理是利用Tomcat的<Context>路径隔离和Nginx的upstream权重：

1. 打两个WAR包：myapp-v1.war（老版本）、myapp-v2.war（新版本）
2. 部署到同一台Tomcat：

   <!-- $TOMCAT_HOME/conf/server.xml --> <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true"> <Context path="/myapp" docBase="myapp-v1.war" reloadable="true"/> <Context path="/myapp-v2" docBase="myapp-v2.war" reloadable="true"/> </Host>

3. Nginx配置按Cookie分流：

   upstream myapp_cluster { server 127.0.0.1:8080 weight=95; # v1占95% server 127.0.0.1:8080 weight=5; # v2占5%，路径为/myapp-v2 } location /myapp/ { if ($cookie_gray_version = "v2") { rewrite ^/myapp/(.*)$ /myapp-v2/$1 break; } proxy_pass http://myapp_cluster;