Debian 上选择 Tomcat 版本的建议
一 选择原则
- 优先选择仍在维护的稳定主线版本，并结合应用所需的 Java/Jakarta EE 规范 与现有依赖的兼容性来确定主次版本。
- 在满足功能与合规的前提下，尽量使用较新的小版本（包含安全修复与稳定性改进），避免跨多个大版本跳跃。
- 若运行在 Debian 稳定版，优先用发行版仓库提供的版本；如需更新功能或修复，可评估官方二进制包或容器化方案，但要权衡维护成本与兼容性。
二 版本与 JDK 及规范对应关系
下表汇总常见 Tomcat 主版本与所需 JDK 及实现的 Jakarta EE/Servlet 规范，便于对齐应用需求与运行时环境。
| Tomcat 主版本 |
所需 JDK |
主要规范与特性 |
| 9.0.x |
Java 8+ |
Servlet 4.0、JSP 2.3、EL 3.0、WebSocket 1.1、JASPIC 1.1（Java EE 8 基线） |
| 8.5.x |
Java 7+ |
与 8.0 相同的规范基线，提供 HTTP/2（需 Tomcat Native/APR）、SNI、OpenSSL/JSSE 支持；删除 BIO 与 Comet |
| 7.0.x |
Java 6+ |
Servlet 3.0、JSP 2.2、EL 2.2；包含内存泄漏检测、CSRF 保护等改进 |
说明：
- 若应用需要 HTTP/2，Tomcat 8.5.x/9.0.x 支持；在 Java 8 上启用 8.5.x 的 HTTP/2 通常需安装 Tomcat Native 库。
- 规范与特性差异会直接影响 API 可用性与行为，升级前请在测试环境验证关键路径。
三 场景化推荐
- 新项目或允许适度升级：优先选 Tomcat 9.0.x + Java 11+（或至少 Java 8），在规范、性能与后续支持上更均衡，便于承接后续 Jakarta EE 演进。
- 需沿用 Java 8 且要 HTTP/2：选 Tomcat 9.0.x；若因环境限制使用 8.5.x，务必准备 Tomcat Native/APR 以启用 HTTP/2。
- 强依赖 Java 7 的老系统：选 Tomcat 8.5.x（8.0 已停止开发，不建议继续新用）。
- 仅维护存量且无法升级 JDK：选 Tomcat 7.0.x，但应尽快规划迁移（安全与兼容性风险随时间上升）。
- 强调“开箱即用”和长期系统一致性（如企业内网、合规审计）：优先 Debian 稳定版仓库的打包版本，减少自维护成本；如需新特性，再评估官方二进制或容器化。
四 安全与维护要点
- 避免已知风险版本：历史上 Debian/Ubuntu 的 Tomcat 打包 init 脚本曾出现本地提权漏洞（如 CVE-2016-1240），受影响包包括 Tomcat 6/7/8 的特定版本，修复方式是升级到包含补丁的版本。生产环境应定期更新系统与 Tomcat 包，并最小化以 tomcat 非特权用户运行。
