Debian 上选择 Tomcat 版本的核心原则
- 以应用的Java 版本与Jakarta EE 包名为第一约束，其次再看Debian 版本的软件仓库支持与安全维护周期。
- 明确所需规范：如 Servlet 4.0 / JSP 2.3 / EL 3.0 / WebSocket 1.1 / JASPIC 1.1 对应 Tomcat 9.x；Servlet 3.1 / JSP 2.3 / EL 3.0 / WebSocket 1.1 对应 Tomcat 8.5.x；Servlet 3.0 / JSP 2.2 / EL 2.2 对应 Tomcat 7.x。
- 关注特性差异：HTTP/2 在 Tomcat 8.5+ 提供（8.5 需 Tomcat Native 库；9.0 在 Java 9+ 原生支持或借助 Native 库），TLS/SNI 能力也随版本增强。
- 优先选择仍在维护的稳定主线版本，避免 EOL 分支（如 Tomcat 8.0.x 已停止开发，官方建议升级至 8.5.x 或更高）。
版本选择矩阵
| 场景 |
推荐主线 |
对应 Java 版本 |
规范与特性要点 |
备注 |
| 新项目，Java 8 |
Tomcat 9.x |
Java 8+ |
Servlet 4.0、HTTP/2（Java 9+ 原生或借助 Native） |
生态成熟、兼容性好 |
| 新项目，Java 11+ |
Tomcat 10.x |
Java 11+ |
包名迁移至 Jakarta EE（javax.* → jakarta.*） |
需评估应用改动成本 |
| 存量项目，Java 8，稳定优先 |
Tomcat 9.x |
Java 8+ |
与 8.5 相比功能更全，生命周期更长 |
推荐作为 8.5 的升级目标 |
| 存量项目，Java 7 |
Tomcat 8.5.x |
Java 7+ |
仍具 HTTP/2（需 Native）、JASPIC 1.1 |
8.0 已 EOL，不建议继续停留 |
| 老项目，Java 6 |
Tomcat 7.x |
Java 6+ |
Servlet 3.0 时代特性 |
强烈建议规划升级路线 |
| 说明：Tomcat 与 JDK、规范的对应关系以及 HTTP/2、TLS/SNI 等能力如上表所示；若你的应用使用 javax.servlet 等旧包名，Tomcat 10+ 的 Jakarta 命名空间将不兼容，需要代码与依赖迁移。 |
|
|
|
|
Debian 版本与仓库建议
- Debian 12（Bookworm）：官方仓库通常提供 Tomcat 9（匹配 Java 17 的默认 JDK），适合生产使用与长期维护。
- Debian 11（Bullseye）：官方仓库通常提供 Tomcat 9，同样适合生产环境。
- Debian 10（Buster）：官方仓库通常提供 Tomcat 9，但已进入 LTS 维护末期，建议规划升级至更新 Debian 版本以获得更长安全支持。
- 如需 Tomcat 10+（Jakarta 命名空间），常见做法是使用上游官方二进制包或容器镜像，而非系统仓库版本，以便获得较新的主线特性与修复。
快速决策清单
- 你的应用运行在 Java 8 且依赖 javax.（jakarta. 尚未迁移） → 选 Tomcat 9.x。
- 你的应用已迁移到 Jakarta EE 9+（jakarta.*） 且运行在 Java 11+ → 选 Tomcat 10.x。
- 你依赖 HTTP/2 且运行在 Java 8 → 选 Tomcat 9.x 并部署 Tomcat Native 库；若运行在 Java 9+，9.x 可原生启用 HTTP/2。
- 你追求更长安全维护周期与更稳生态 → 优先 Tomcat 9.x；避免使用 8.0.x/7.x 等老分支。
- 你希望与 Debian 12 官方仓库保持一致 → 选 Tomcat 9.x（仓库提供）。
升级与迁移注意事项
- 跨主版本（如 Tomcat 9 → 10）涉及 Java EE → Jakarta EE 命名空间迁移，应用代码、依赖与配置（如 web.xml、Filter/Listener、JNDI 资源）需相应调整，先小流量灰度验证。
- 升级前务必备份：如 /opt/tomcat、conf/（server.xml、context.xml、web.xml）、数据与密钥库；采用“并行目录 + 符号链接/切换 systemd 单元”方式降低切换风险。
- 若从 8.0.x 升级，先迁移到 8.5.x（同规范线），再评估到 9.x/10.x，以减少一次性变更面。
