# Tomcat 部署 Java Web 应用

Tomcat 版本需要与 Java 版本及应用使用的 Servlet API 匹配。旧应用的 javax 与新环境的 jakarta 迁移可能需要改代码。

更新日期：2026-09-16

规范地址：https://stock.iftalking.com/guides/tomcat/

## 1. 先匹配应用、Java 和 Tomcat

Tomcat 运行 Java Web 应用，不是完整的所有 Jakarta EE 服务集合。先查看项目使用的 Servlet/Jakarta API、Java 版本和打包方式，再选择官方仍支持的 Tomcat 系列。

旧应用使用 `javax.*`，新 Jakarta 应用使用 `jakarta.*`，不能只把 WAR 放进更高版本就认为一定兼容。Tomcat 11 需要 Java 17 或更高，具体应用依赖还可能要求更高版本；以官方版本对照表和应用说明一起核对。

```bash
java -version
```

## 2. 下载官方发行包并隔离运行用户

从 Apache Tomcat 官方下载页选择匹配版本，核对签名或校验值，解压到独立版本目录。给 Tomcat 创建无 sudo 权限的服务用户，仅授予所需目录读写权限，不用 root 长期运行 Web 应用。

区分 CATALINA_HOME（软件安装）与 CATALINA_BASE（实例配置和运行数据）有助于升级。至少记录 conf、webapps、logs 与应用上传目录，避免更新软件时覆盖业务文件。

## 3. 先在本地端口启动测试

检查 `conf/server.xml` 中 HTTP Connector 的端口与绑定地址。由本机反向代理接入时，可让应用端口只监听回环地址；不要把管理器、示例应用和调试端口全部开放。

```bash
/opt/tomcat/bin/catalina.sh run
```

路径按实际安装目录替换。前台模式便于第一次看启动日志；看到启动完成后，从服务器请求配置的本地端口，确认返回预期内容。端口冲突、Java 不匹配和目录权限错误应先修复。

## 4. 部署 WAR 并确认上下文路径

把经过构建和测试的 WAR 放到该实例约定的部署目录，使用应用发布流程完成更新。`myapp.war` 常对应 `/myapp/`，根路径部署有专门命名与配置规则，不要因为访问 `/` 没看到应用就判定部署失败。

数据库连接、环境变量和上传目录应独立配置，秘密不打进 WAR。生产中限制或移除不需要的示例与管理应用；需要管理器时使用受限账户和网络访问范围。

## 5. 配置服务与 HTTPS 反向代理

使用 systemd 以前台方式管理 `catalina.sh run`，设置专用用户、JAVA_HOME 和内存参数。JVM 堆大小只是进程内存的一部分，还需给线程栈、直接内存和系统留余量。

反向代理将 HTTPS 转发给本地 Tomcat，按官方代理说明配置协议、主机和客户端信息，避免生成错误的 HTTP 链接或重定向循环。不要直接信任任意客户端传入的转发头。

## 6. 更新时验证应用与数据

测试登录、数据库读写、文件上传、长请求和错误页面，再验证重启恢复。升级 Tomcat 前记录旧版本、配置差异和 WAR，阅读迁移说明；应用数据库变更需要独立备份与回退。

日志应轮转，管理凭据定期维护。通用部署方法见[后台服务](https://stock.iftalking.com/guides/persistent-jobs/)、[HTTPS](https://stock.iftalking.com/guides/https-certificates/)与[备份恢复](https://stock.iftalking.com/guides/backup-restore/)。


## 完成后检查

测试应用重启和主机重启，确认日志位置、配置备份和回滚包都已保存。

## 参考资料

- [tomcat.apache.org · 项目文档](https://tomcat.apache.org/)