运行JAR包与Tomcat部署WAR包，各自的核心优缺点是什么？

Question

运行JAR包（如Spring Boot Fat Jar）与Tomcat部署WAR包，核心差异在于**部署模型与容器耦合度**。 ✅ JAR优势：内嵌Servlet容器（如Tomcat），启动快、依赖自包含、天然适配云原生（Docker/K8s），运维简单；劣势：内存占用略高、热部署受限、传统Java EE规范（如JNDI、JAAS）支持弱。 ✅ WAR优势：标准Java EE部署方式，可复用企业级Tomcat集群（统一SSL、日志、JVM调优）、支持热部署与多应用共存；劣势：需独立维护Tomcat环境，版本兼容风险高（如Spring Boot 3+不支持WAR部署于Servlet 4.0以下），构建与发布流程更重。 常见问题：Spring Boot 3.x项目误打WAR包导致启动失败；JAR中静态资源路径在反向代理后404；WAR在Tomcat 9+启用HTTP/2需额外配置；二者混用时类加载冲突（如重复引入Tomcat API）。选型应基于团队运维能力、组织基础设施成熟度及长期演进策略。

Answer 1

```html

一、部署模型本质：内嵌容器 vs 外置容器

Spring Boot Fat JAR 本质是「可执行归档」，其 META-INF/MANIFEST.MF 中声明 Start-Class 和 Bootstrap-Classes，通过 org.springframework.boot.loader.JarLauncher 启动内嵌 Tomcat（默认为 TomcatServletWebServerFactory 实例）。而 WAR 包是 Java EE 规范定义的「Web Application Archive」，依赖 Servlet 容器（如 Tomcat）的 Catalina 生命周期管理器加载 ServletContext，由容器统一调度 ServletContainerInitializer。

二、耦合度光谱分析：从紧耦合到松耦合

• JAR 模式：应用与容器强绑定（编译期即引入 spring-boot-starter-web → 传递依赖 tomcat-embed-core），JVM 进程 = 应用进程 = 容器进程；
• WAR 模式：应用与容器解耦，仅依赖 javax.servlet-api（provided scope），运行时由 Tomcat 的 common/shared classloader 提供实现；
• 关键分水岭：spring-boot-starter-tomcat 在 JAR 中为 compile，在 WAR 中必须设为 provided，否则引发 java.lang.LinkageError: loader constraint violation。

三、典型问题诊断树（Mermaid 流程图）

flowchart TD
    A[启动失败] --> B{包类型检查}
    B -->|JAR| C[是否含 spring-boot-maven-plugin?]
    B -->|WAR| D[是否继承 SpringBootServletInitializer?]
    C -->|否| E[MANIFEST.MF 缺失 Start-Class]
    D -->|否| F[ServletContext 初始化失败]
    A --> G{HTTP 404 静态资源}
    G --> H[server.servlet.context-path 是否与反向代理 location 匹配?]
    G --> I[resources.static-locations 是否覆盖了 /static?]

四、版本兼容性矩阵（关键约束）

Spring Boot 版本	支持 WAR 部署?	最低 Servlet API	Tomcat 最低版本	备注
2.7.x	✅ 支持	Servlet 4.0	Tomcat 9.0.65+	仍可部署于 Tomcat 8.5（降级兼容）
3.0.0+	❌ 移除 WAR 支持	Servlet 5.0	Tomcat 10.1.0+	因 Jakarta EE 9 命名空间迁移（javax.* → jakarta.*）
3.2.x	❌ 强制 JAR	Servlet 6.0	Tomcat 10.2.0+	内嵌 Tomcat 默认启用 HTTP/2 + TLS 1.3

五、生产级陷阱与规避策略

1. JNDI 查找失败：JAR 模式下 java:comp/env/jdbc/xxx 不可用 → 解决方案：改用 Spring Boot @ConfigurationProperties 绑定数据源配置；
2. 热部署失效：JAR 的 spring-boot-devtools 仅支持类重载，不支持 JSP/WEB-INF 修改 → WAR 模式下配合 Tomcat reloadable="true" 可实时刷新；
3. HTTP/2 在 WAR 中启用：需在 $CATALINA_HOME/conf/server.xml 的 Connector 中显式添加 protocol="org.apache.coyote.http11.Http11Nio2Protocol" 并配置 ALPN；
4. 类加载冲突：若 JAR 项目错误引入 tomcat-catalina，会与 Tomcat 自身类冲突 → Maven 排除：<exclusion><groupId>org.apache.tomcat</groupId><artifactId>tomcat-catalina</artifactId></exclusion>；

六、选型决策框架（四维评估模型）

建议采用以下加权打分法（每项 1–5 分）：

• 运维成熟度：现有团队是否具备容器化编排能力？K8s Operator 管理 JAR 比 Tomcat Operator 更轻量；
• 合规要求：金融行业常强制要求 JNDI/JAAS，此时 WAR 是唯一合规路径；
• 发布频率：日更场景优先 JAR（CI/CD 流水线单 artifact）；月更且多系统共用中间件 → WAR；
• 可观测性基建：已有 Prometheus+Grafana+ELK 的组织，JAR 的 Micrometer 原生指标采集更易对齐；

```