SpringBoot项目部署实战：JAR与WAR包部署详解及服务器配置

原创于 2026-08-03 11:39:45 发布 · 426 阅读

本内容遵循CC 4.0 BY-SA版权协议

1. 项目概述：从开发到上线的最后一公里

搞SpringBoot项目，最后一步也是最关键的一步，就是把它扔到服务器上跑起来。很多新手朋友在本地开发得风生水起，一到部署环节就卡壳，面对各种打包方式、服务器环境一头雾水。今天，我就结合自己踩过的坑，把SpringBoot项目部署到服务器的两种主流方式—— JAR包部署 和 WAR包部署 ——掰开揉碎了讲清楚。这不仅仅是把文件传上去那么简单，它涉及到项目打包方式、服务器环境配置、启动策略和后期运维监控等一系列选择。无论你是想把个人博客上线，还是为公司部署一个微服务，理解这两种方式的差异和适用场景，都能让你在“最后一公里”走得更加稳健。

简单来说，JAR包部署是SpringBoot官方力推的“一站式”方案，内置Web容器（默认Tomcat），开箱即用；而WAR包部署则是更传统的Java Web应用部署方式，需要依赖外部的Web服务器（如Tomcat、Jetty）。选择哪种，取决于你的项目需求、团队技术栈和运维习惯。接下来，我们就深入这两种方式的内部，看看它们具体是怎么玩的。

2. 核心思路与方案选型：JAR vs WAR

在动手之前，我们得先想明白为什么要分这两种方式，以及它们各自的“脾气秉性”是什么。这决定了你后续所有操作的逻辑。

2.1 JAR包部署：独立运行的“瑞士军刀”

SpringBoot的设计哲学就是“约定大于配置”，而可执行JAR（Executable Jar）正是这一哲学的完美体现。它把应用本身、依赖的第三方库（JAR包），以及一个内嵌的Web服务器（默认是Tomcat）全部打包进一个单独的JAR文件中。你可以把它理解为一个自带运行环境的完整应用包。

它的核心优势在于：

高度独立与便携 ：一个JAR文件就是全部。你不需要在目标服务器上预装Tomcat，只需要有合适版本的Java运行环境（JRE）即可。这极大地简化了环境准备和迁移工作，特别适合云原生、容器化（如Docker）部署。
部署简单 ：部署命令极其简单，通常就是 java -jar yourapp.jar 。配合 nohup 或系统服务（如systemd），可以轻松实现后台运行和开机自启。
微服务友好 ：在微服务架构中，每个服务都是独立的、可快速启动和停止的单元。可执行JAR的独立特性与微服务的理念天然契合。

但它也有需要考虑的地方：

“胖” ：由于包含了所有依赖和内嵌服务器，JAR文件体积会比较大。
服务器定制化受限 ：你使用的是内嵌的、由SpringBoot管理的Tomcat。如果你想对Tomcat进行一些深度定制（比如修改server.xml中某些高级配置），虽然也可以通过SpringBoot的配置属性或编程方式实现，但不如直接操作外部Tomcat直观和灵活。

2.2 WAR包部署：传统而灵活的“组件装配”

WAR（Web Application Archive）包是Java EE时代的标准部署格式。在这种方式下，你的SpringBoot应用被打包成一个不包含Web服务器的WAR文件。部署时，你需要将这个WAR包放入一个外部的、已经安装好的Web服务器（如Tomcat、Jetty、Undertow）的特定目录（通常是 webapps ）中，由这个外部的服务器来加载和运行你的应用。

它的核心优势在于：

服务器资源共享与统一管理 ：在一台物理机或虚拟机上，你可以部署多个WAR应用到同一个Tomcat实例中，共享其端口、线程池等资源。运维人员可以集中管理这一个Tomcat服务器，进行统一的监控、调优和安全配置。
服务器深度定制 ：你可以完全掌控外部Tomcat的所有配置（ server.xml , context.xml , web.xml 等），实现更精细的性能调优、安全策略和虚拟主机配置。这对于有严格合规要求或复杂部署场景的企业级应用很重要。
与遗留系统集成 ：如果你的公司已有成熟的、基于传统WAR包部署的Java EE运维体系，那么将SpringBoot应用打包成WAR可以无缝融入现有流程，降低学习和迁移成本。

它的“包袱”在于：

环境依赖复杂 ：部署前必须确保目标服务器上正确安装并配置了兼容版本的Web服务器和JRE。
部署步骤稍多 ：需要管理Web服务器本身，部署过程涉及文件拷贝、服务器重启等操作。
启动稍慢 ：外部Tomcat启动本身需要时间，然后再加载WAR应用。

选择建议 ：对于绝大多数新建的SpringBoot项目，尤其是微服务、云原生应用， 强烈推荐使用JAR包部署 ，简单粗暴效率高。只有当你有明确的“多应用共享服务器”、“需要深度定制外部Tomcat”或“必须兼容现有企业部署规范”需求时，才考虑WAR包部署。

3. 实操准备：项目配置与打包

无论选择哪种方式，我们都需要从项目配置开始。这里我以一个简单的SpringBoot Web项目为例，构建工具使用Maven。

3.1 基础项目结构

假设你的项目 pom.xml 最初是这样的（SpringBoot 2.x 或 3.x 通用结构）：

<?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> <!-- 或 3.1.x -->
        <relativePath/>
    </parent>
    <groupId>com.example</groupId>
    <artifactId>my-springboot-app</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <name>my-springboot-app</name>
    <description>Demo project for Spring Boot</description>
    <properties>
        <java.version>11</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-maven-plugin 插件，它是打包的关键。

3.2 打包成可执行JAR（默认方式）

这是SpringBoot的默认打包方式，你几乎不需要做任何额外配置。 在项目根目录下执行Maven打包命令：

mvn clean package

命令执行成功后，在 target/ 目录下，你会找到两个主要的JAR文件：

my-springboot-app-0.0.1-SNAPSHOT.jar ：这就是可执行的“胖JAR”（Fat Jar）。你可以用 java -jar 直接运行它。
my-springboot-app-0.0.1-SNAPSHOT.jar.original ：这是标准的、不包含依赖的“瘦JAR”，通常我们不用它。

验证JAR包：

# 查看JAR包结构，确认是否包含内嵌依赖
jar tf target/my-springboot-app-0.0.1-SNAPSHOT.jar | grep BOOT-INF/lib
# 应该能看到一堆依赖库
# 本地快速测试运行
java -jar target/my-springboot-app-0.0.1-SNAPSHOT.jar

如果应用正常启动，控制台打印出SpringBoot的Banner和端口信息，说明JAR包打包成功。

3.3 打包成WAR包

如果你决定使用WAR包部署，需要对项目进行一些改造。

第一步：修改打包类型 在 pom.xml 中，将 <packaging> 标签的值从默认的 jar 改为 war 。

<groupId>com.example</groupId>
<artifactId>my-springboot-app</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>war</packaging> <!-- 关键修改 -->

第二步：排除内嵌Tomcat依赖（关键！） 既然要部署到外部Tomcat，就必须排除SpringBoot内嵌的Tomcat，否则会产生冲突。修改 spring-boot-starter-web 依赖：

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
        <!-- 排除内嵌的Tomcat -->
        <exclusions>
            <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>
    <!-- 其他依赖 -->
</dependencies>

<scope>provided</scope> 意味着这个依赖在打包时不会被包含进WAR文件，因为目标服务器的Tomcat会提供它。

第三步：修改主启动类 SpringBoot应用需要继承 SpringBootServletInitializer 并重写 configure 方法，以便外部Servlet容器（如Tomcat）能够识别并启动它。

package com.example.demo;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.boot.builder.SpringApplicationBuilder;
import org.springframework.boot.web.servlet.support.SpringBootServletInitializer;

@SpringBootApplication
public class MySpringbootAppApplication extends SpringBootServletInitializer { // 继承

    @Override
    protected SpringApplicationBuilder configure(SpringApplicationBuilder application) {
        // 指定配置源，即本类
        return application.sources(MySpringbootAppApplication.class);
    }

    public static void main(String[] args) {
        SpringApplication.run(MySpringbootAppApplication.class, args);
    }
}

第四步：重新打包 再次执行打包命令：

mvn clean package

成功后，在 target/ 目录下，你会找到 my-springboot-app-0.0.1-SNAPSHOT.war 文件。这个WAR包体积会比可执行JAR小，因为它不包含内嵌的Tomcat和那些 provided 范围的依赖。

4. 服务器环境准备与部署实战

打包完成后，我们就要在服务器上动真格的了。假设你有一台干净的Linux服务器（如CentOS 7/8 或 Ubuntu 20.04/22.04）。

4.1 公共环境准备：安装Java

无论JAR还是WAR，Java运行环境是必须的。建议安装JDK而非仅JRE，便于排查问题。

# 以Ubuntu为例，安装OpenJDK 11
sudo apt update
sudo apt install openjdk-11-jdk -y

# 验证安装
java -version
# 输出应包含 “openjdk version “11.x.x””

4.2 方式一：JAR包部署与运行

1. 上传JAR文件 使用 scp 或 rsync 等工具将打包好的JAR文件上传到服务器。我习惯放在 /opt/app/ 目录下，并建立以应用名命名的子目录。

# 本地终端执行
scp target/my-springboot-app-0.0.1-SNAPSHOT.jar user@your-server-ip:/opt/app/myapp/

2. 最简单的运行与测试 SSH登录服务器，进入目录直接运行：

cd /opt/app/myapp
java -jar my-springboot-app-0.0.1-SNAPSHOT.jar

应用启动后，你应该能在服务器日志中看到熟悉的SpringBoot启动信息。此时，在浏览器访问 http://服务器IP:8080 （假设默认端口8080）应该能看到应用页面。

3. 生产环境运行方案（关键！） 直接在前台运行 java -jar 会占用终端，且退出终端后进程会终止。这绝对不适合生产环境。以下是几种生产级方案：

方案A：使用 nohup 后台运行（快速测试/临时方案）

nohup java -jar my-springboot-app-0.0.1-SNAPSHOT.jar > app.log 2>&1 &

nohup ：忽略挂断信号，终端退出后进程继续运行。
> app.log ：将标准输出重定向到 app.log 文件。
2>&1 ：将标准错误也重定向到标准输出（即同一个日志文件）。
& ：在后台运行。
查看日志 ： tail -f app.log
停止应用 ：先 ps -ef | grep java 找到进程ID（PID），然后 kill -9 PID 。

方案B：配置为Systemd服务（推荐，最规范） 这是Linux系统管理后台服务的标准方式，可以实现开机自启、自动重启、集中日志管理。

创建服务配置文件：

sudo vim /etc/systemd/system/myapp.service

写入以下内容（根据实际情况修改）：

[Unit]
Description=My SpringBoot Application
After=syslog.target network.target

[Service]
Type=simple
User=appuser # 建议创建一个非root用户来运行应用，更安全
WorkingDirectory=/opt/app/myapp
ExecStart=/usr/bin/java -Xms512m -Xmx1024m -jar my-springboot-app-0.0.1-SNAPSHOT.jar
# 重要：指定运行配置文件，例如 application-prod.yml
Environment=SPRING_PROFILES_ACTIVE=prod
# 内存溢出时自动生成HeapDump
Environment=JAVA_OPTS=-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/opt/app/myapp/heapdump.hprof
# 配置日志输出到系统日志（可选）
StandardOutput=journal
StandardError=journal
SuccessExitStatus=143
# 应用崩溃后自动重启
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target

-Xms512m -Xmx1024m ：设置JVM堆内存初始大小和最大大小，根据你的应用实际需求调整。
SPRING_PROFILES_ACTIVE=prod ：激活名为 prod 的Spring配置文件（如 application-prod.yml ），用于加载生产环境配置（数据库地址、日志级别等）。

启用并启动服务：

sudo systemctl daemon-reload # 重载配置
sudo systemctl enable myapp.service # 开机自启
sudo systemctl start myapp.service # 启动服务
sudo systemctl status myapp.service # 查看状态

管理命令：

sudo systemctl stop myapp.service # 停止
sudo systemctl restart myapp.service # 重启
sudo journalctl -u myapp.service -f # 查看日志（跟随模式）

4.3 方式二：WAR包部署到外部Tomcat

1. 安装和配置Tomcat

# 下载Tomcat（以9.x为例）
wget https://archive.apache.org/dist/tomcat/tomcat-9/v9.0.85/bin/apache-tomcat-9.0.85.tar.gz
# 解压
tar -xzf apache-tomcat-9.0.85.tar.gz -C /opt/
sudo mv /opt/apache-tomcat-9.0.85 /opt/tomcat9

# 创建运行Tomcat的专用用户（安全考虑）
sudo useradd -r -m -d /opt/tomcat9 -s /bin/false tomcat
sudo chown -R tomcat:tomcat /opt/tomcat9
sudo chmod -R u+x /opt/tomcat9/bin

# 配置环境变量（可选，方便操作）
echo ‘export CATALINA_HOME=/opt/tomcat9’ | sudo tee -a /etc/profile.d/tomcat.sh
echo ‘export PATH=$PATH:$CATALINA_HOME/bin’ | sudo tee -a /etc/profile.d/tomcat.sh
source /etc/profile.d/tomcat.sh

2. 部署WAR文件 将打包好的WAR文件拷贝到Tomcat的 webapps/ 目录下。Tomcat会自动解压并加载它。

# 上传WAR文件到服务器后，移动到Tomcat目录
sudo cp /path/to/my-springboot-app-0.0.1-SNAPSHOT.war /opt/tomcat9/webapps/
# 修改所有者
sudo chown tomcat:tomcat /opt/tomcat9/webapps/my-springboot-app-0.0.1-SNAPSHOT.war

注意：WAR包在 webapps/ 目录下的访问上下文路径（Context Path）默认就是文件名（不含 .war 后缀），即 my-springboot-app-0.0.1-SNAPSHOT 。如果你想用根路径访问，可以把WAR文件名改为 ROOT.war 。

3. 启动Tomcat并验证

# 切换到tomcat用户启动（避免以root运行）
sudo -u tomcat /opt/tomcat9/bin/startup.sh
# 查看日志
tail -f /opt/tomcat9/logs/catalina.out

在日志中看到类似 “ org.apache.catalina.startup.Catalina.start Server startup in [xxxx] milliseconds ” 的信息，并且有你的SpringBoot应用启动日志，说明部署成功。

4. 访问应用 假设Tomcat运行在8080端口，WAR文件名为 myapp.war ，那么访问地址为： http://服务器IP:8080/myapp/ 。如果你将WAR重命名为 ROOT.war ，则访问根路径即可： http://服务器IP:8080/ 。

5. 配置为Systemd服务（同样推荐） 为Tomcat配置systemd服务，便于管理。

sudo vim /etc/systemd/system/tomcat9.service

内容如下：

[Unit]
Description=Apache Tomcat 9
After=network.target

[Service]
Type=forking
User=tomcat
Group=tomcat
Environment=“JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64” # 根据你的JDK路径修改
Environment=“CATALINA_PID=/opt/tomcat9/temp/tomcat.pid”
Environment=“CATALINA_HOME=/opt/tomcat9”
Environment=“CATALINA_BASE=/opt/tomcat9”
ExecStart=/opt/tomcat9/bin/startup.sh
ExecStop=/opt/tomcat9/bin/shutdown.sh
Restart=on-failure

[Install]
WantedBy=multi-user.target

然后启用服务：

sudo systemctl daemon-reload
sudo systemctl enable tomcat9
sudo systemctl start tomcat9
sudo systemctl status tomcat9

5. 进阶配置与优化要点

部署上线只是第一步，要让应用稳定高效运行，还需要一些“调教”。

5.1 JAR部署的配置与优化

指定运行配置文件 ：生产环境的数据库密码、Redis地址等敏感或环境特定配置，绝不能写在 application.yml 里。使用 --spring.profiles.active 参数或 SPRING_PROFILES_ACTIVE 环境变量指定。
```
java -jar myapp.jar --spring.profiles.active=prod
# 或者在systemd服务文件中设置 Environment=SPRING_PROFILES_ACTIVE=prod
```
JVM内存与GC优化 ：根据服务器内存和应用负载调整JVM参数。对于Web应用，G1垃圾收集器是个不错的默认选择。
```
# 在systemd的ExecStart中调整
ExecStart=/usr/bin/java -server -Xms2g -Xmx2g -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -jar myapp.jar
```
- -Xms2g -Xmx2g ：将堆内存初始值和最大值设为相同，避免运行时动态调整带来的性能波动。
- -XX:+UseG1GC ：使用G1垃圾收集器。
- -XX:MaxGCPauseMillis=200 ：设定GC最大停顿时间目标（毫秒）。

应用特定端口 ：在 application-prod.yml 中配置：

server:
  port: 8081 # 使用非默认端口，避免冲突

5.2 WAR部署在Tomcat中的优化

配置Context（上下文） ：直接在 webapps/ 下放WAR是最简单的方式，但更规范的做法是在 conf/Catalina/localhost/ 下创建独立的XML上下文文件。例如，创建 /opt/tomcat9/conf/Catalina/localhost/myapp.xml ：
```
<?xml version=“1.0” encoding=“UTF-8”?>
<Context docBase=“/opt/app/wars/my-springboot-app.war” path=“/myapp” reloadable=“false”>
    
    
</Context>
```
- docBase ：WAR文件的绝对路径或解压后的目录路径。
- path ：访问应用的上下文路径。
- reloadable=“false” ：生产环境设为false以提高性能，修改后需要重启Tomcat。

Tomcat服务器优化 ：编辑 conf/server.xml 。

连接器优化 ：修改


     <Connector port=“8080” ...>

节点。

<Connector port=“8080” protocol=“HTTP/1.1”
           connectionTimeout=“20000”
           redirectPort=“8443”
           maxThreads=“200” <!-- 最大线程数，根据CPU核心数和业务类型调整 -->
           minSpareThreads=“10”
           acceptCount=“100” <!-- 等待队列长度 -->
           compression=“on”
           compressionMinSize=“1024”
           compressableMimeType=“text/html,text/xml,text/plain,text/css,application/json,application/javascript”/>

关闭AJP连接器 ：如果不用Apache HTTPD做前端代理，可以注释掉  。

设置JVM参数 ：在Tomcat的启动脚本 bin/setenv.sh （如果没有则创建）中设置：

# /opt/tomcat9/bin/setenv.sh
export JAVA_OPTS=“-server -Xms4g -Xmx4g -XX:+UseG1GC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/opt/tomcat9/logs”

这会对所有部署在该Tomcat上的应用生效。

6. 部署后的监控、维护与问题排查

应用跑起来不是终点，确保它持续健康运行才是关键。

6.1 基础监控与日志

进程状态 ：
- JAR部署： systemctl status myapp 或 ps -ef | grep java 。
- WAR部署： systemctl status tomcat9 或检查Tomcat进程。
日志查看 ：
- JAR部署（Systemd）： sudo journalctl -u myapp.service -f -n 100 。
- JAR部署（nohup）： tail -f /opt/app/myapp/app.log 。
- WAR部署： tail -f /opt/tomcat9/logs/catalina.out 以及应用自身的日志文件（如果配置了输出到文件，如 /opt/tomcat9/logs/myapp.log ）。
端口监听检查 ： netstat -tlnp | grep :8080 （查看端口是否被正确监听）。

6.2 常见问题与排查实录

问题1： java -jar 启动后，端口被占用或无法访问。

排查：
1. netstat -tlnp | grep :端口号 查看端口是否被其他进程占用。
2. 检查应用日志，看是否有启动失败的错误信息。常见错误包括：数据库连接失败、Redis连接失败、配置文件读取错误等。
3. 检查服务器防火墙（如 firewalld 或 ufw ）是否开放了对应端口。
```
sudo firewall-cmd --list-ports # CentOS
sudo ufw status # Ubuntu
```

问题2：WAR包部署到Tomcat后，访问出现404错误。

排查：
1. 检查Tomcat日志 catalina.out 和 localhost.log ，看WAR是否成功解压和加载。寻找是否有 Deployment of web application archive [/path/to/war] has finished in [xx] ms 这样的成功信息，或者具体的加载失败错误（如类冲突、缺少依赖）。
2. 确认访问的URL路径是否正确。如果WAR文件名为 myapp-v1.war ，访问路径应为 http://ip:port/myapp-v1/ 。
3. 检查应用本身的控制器（Controller）映射路径。SpringBoot应用在WAR中运行时，所有的 @RequestMapping 路径前面会自动加上WAR的上下文路径。

问题3：应用运行一段时间后内存占用过高，响应变慢甚至OOM（OutOfMemory）。

排查：
1. 使用 jps 或 ps 找到Java进程ID。
2. 使用 jstat -gc PID 1000 10 观察垃圾回收情况，看Full GC是否频繁。
3. 使用 jmap -heap PID 查看堆内存各区域使用情况。
4. 如果配置了 -XX:+HeapDumpOnOutOfMemoryError ，在OOM发生时会在指定路径生成堆转储文件（ .hprof ）。可以使用MAT（Eclipse Memory Analyzer）或VisualVM等工具分析该文件，找出内存泄漏的对象。
应对：根据分析结果调整JVM参数（如增大堆内存 -Xmx ），或修复应用代码中的内存泄漏问题。

问题4：如何优雅地停止应用？

JAR部署 ：对于 java -jar 启动的应用，在终端按 Ctrl+C 会发送SIGINT信号，SpringBoot会优雅关闭（完成当前请求处理）。对于systemd服务， systemctl stop 命令也会发送SIGTERM信号触发优雅关闭。
WAR部署 ：通过 systemctl stop tomcat9 或执行 shutdown.sh 脚本，Tomcat会依次通知所有Web应用进行优雅关闭。
重要：在你的SpringBoot应用中，可以通过实现 DisposableBean 接口或使用 @PreDestroy 注解，来定义应用关闭时需要执行的清理逻辑（如关闭线程池、释放连接等）。

6.3 版本更新与回滚

对于JAR部署：

上传新的JAR包到服务器（如 myapp-0.0.2-SNAPSHOT.jar ）。
停止旧服务： sudo systemctl stop myapp 。
（可选）备份旧JAR包和日志。
替换JAR包文件。
启动新服务： sudo systemctl start myapp 。
密切监控日志，确认启动成功。
回滚：如果新版本有问题，重复上述步骤，用备份的旧JAR包替换回来并重启。

对于WAR部署：

上传新的WAR包。
停止Tomcat： sudo systemctl stop tomcat9 。
备份旧的WAR文件或解压目录（通常位于 webapps/myapp 和 work/Catalina/localhost/myapp ）。
删除 webapps/ 下旧的应用目录（如 myapp ）和旧的WAR文件，放入新的WAR文件。
启动Tomcat： sudo systemctl start tomcat9 。
回滚：用备份的旧WAR文件替换，并清理Tomcat的 work 和 temp 目录中对应的缓存，然后重启Tomcat。

实操心得 ：在生产环境，我强烈建议将上述步骤脚本化，并纳入持续集成/持续部署（CI/CD）流程，例如使用Jenkins、GitLab CI等工具。每次部署前，在预发布环境进行充分测试。对于关键业务应用，可以采用“蓝绿部署”或“金丝雀发布”等策略，先让一小部分流量切到新版本，观察无误后再全量上线，最大化降低发布风险。无论是JAR还是WAR，清晰的部署文档、可重复的自动化脚本和严谨的发布流程，是保障线上稳定性的基石。

标签