从Jar到War：SpringBoot项目部署方式深度解析与IDEA实战指南

在微服务架构盛行的今天，SpringBoot凭借其"约定优于配置"的理念成为Java开发者的首选框架。但当我们真正要将项目部署到生产环境时，一个看似简单却至关重要的选择摆在面前：该将项目打包为Jar还是War？这个决策不仅影响部署方式，更关系到后续的运维成本和系统扩展性。本文将带您深入理解两种打包方式的本质区别，并通过IDEA实战演示如何根据实际需求灵活切换。

1. Jar与War的本质区别：不只是容器那么简单

许多开发者简单地认为Jar和War的区别仅在于是否使用外部Tomcat，这种理解过于表面。实际上，两种打包方式代表着不同的架构哲学和部署策略。

Jar包的核心特点 ：

• 内嵌服务器（默认Tomcat）：无需额外安装Web容器
• 独立可执行：通过 java -jar 命令直接运行
• 轻量级部署：适合云原生和微服务架构
• 默认打包方式：SpringBoot项目的天然选择

War包的传统优势 ：

• 兼容传统Java EE部署模式
• 可部署到任意Servlet 3.0+容器（Tomcat、Jetty等）
• 便于与现有企业级中间件集成
• 支持多应用共享容器资源

从技术实现角度看，关键差异在于 spring-boot-maven-plugin 的处理方式。当打包为Jar时，插件会执行 repackage 操作，将依赖和内嵌服务器打包成一个可执行的"fat jar"。而War包则保留了传统Java Web应用的结构，将依赖放在 WEB-INF/lib 目录下。

提示：选择打包方式时，除了考虑部署环境，还需评估团队的技术栈熟悉度和长期维护成本。

2. 何时选择Jar？何时选择War？

2.1 适合Jar包的典型场景

• 云原生部署 ：Kubernetes、Docker Swarm等容器编排平台
• 微服务架构 ：需要快速扩展和独立部署的服务
• Serverless环境 ：函数计算等无服务器场景
• 开发测试环境 ：需要快速启动和迭代的场景

<!-- 典型SpringBoot Jar打包配置 -->
<plugin>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-maven-plugin</artifactId>
</plugin>

2.2 适合War包的特殊情况

• 企业传统环境 ：已有Tomcat集群且运维规范严格
• 遗留系统集成 ：需要与旧版Java EE系统共存
• 资源受限环境 ：多个应用共享服务器资源
• 特殊安全要求 ：需要容器级别的安全隔离

<!-- War包需要修改打包类型并排除内嵌Tomcat -->
<packaging>war</packaging>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-tomcat</artifactId>
    <scope>provided</scope>
</dependency>

3. IDEA中Jar转War实战指南

3.1 基础配置改造

1. 修改 pom.xml 中的打包类型：

   <packaging>war</packaging>
   

2. 排除内嵌Tomcat依赖：

   <dependency>
       <groupId>org.springframework.boot</groupId>
       <artifactId>spring-boot-starter-tomcat</artifactId>
       <scope>provided</scope>
   </dependency>
   

3. 添加Servlet API依赖（SpringBoot 2.4+需要）：

   <dependency>
       <groupId>javax.servlet</groupId>
       <artifactId>javax.servlet-api</artifactId>
       <scope>provided</scope>
   </dependency>
   

3.2 初始化Servlet容器

创建 ServletInitializer 类继承 SpringBootServletInitializer ：

public class ServletInitializer extends SpringBootServletInitializer {
    @Override
    protected SpringApplicationBuilder configure(SpringApplicationBuilder application) {
        return application.sources(YourApplication.class);
    }
}

3.3 两种打包方式对比

操作方式	优点	缺点	适用场景
IDEA图形界面打包	可视化操作，简单直观	多模块项目支持有限	简单项目快速打包
Maven命令打包	支持复杂配置，可自动化	需要熟悉Maven生命周期	企业级CI/CD流程

4. 多模块项目的特殊处理

在SpringCloud多模块项目中，打包时需要特别注意模块间的依赖关系。以下是常见问题的解决方案：

4.1 依赖模块找不到问题

在父pom中添加 spring-boot-maven-plugin 并配置 repackage ：

<plugin>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-maven-plugin</artifactId>
    <executions>
        <execution>
            <goals>
                <goal>repackage</goal>
            </goals>
        </execution>
    </executions>
</plugin>

4.2 公共模块特殊配置

在被依赖的公共模块（如utils、entity）中配置分类器：

<build>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
            <configuration>
                <classifier>exec</classifier>
            </configuration>
        </plugin>
    </plugins>
</build>

4.3 打包顺序建议

1. 清理所有模块： mvn clean
2. 安装依赖模块： mvn install
3. 打包主应用： mvn package

注意：在多模块项目中，确保先安装依赖模块再打包主应用，避免类找不到的错误。

5. 高级配置与优化技巧

5.1 排除不必要的依赖

通过 exclude 减少War包体积：

<exclusions>
    <exclusion>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-logging</artifactId>
    </exclusion>
</exclusions>

5.2 自定义War包名称

在 pom.xml 中配置最终War包名称：

<build>
    <finalName>myapp</finalName>
</build>

5.3 资源过滤与配置分离

将配置文件外置以便于环境切换：

<resources>
    <resource>
        <directory>src/main/resources</directory>
        <filtering>true</filtering>
        <excludes>
            <exclude>application*.yml</exclude>
        </excludes>
    </resource>
</resources>

5.4 部署后的监控与维护

• 配置Tomcat的 manager 应用进行在线部署
• 使用SpringBoot Actuator进行健康检查
• 设置合理的JVM参数和线程池大小

在实际项目部署中，我们遇到过因打包方式选择不当导致的性能问题。一个电商系统最初使用War包部署在传统Tomcat集群，后来迁移到Kubernetes环境后改为Jar包部署，不仅资源利用率提高了30%，部署时间也从原来的15分钟缩短到2分钟。