Java 17+项目应选Tomcat 10.1.x（原生支持Jakarta EE 9+），Windows用户下zip包避免exe安装版，Mac/Linux需赋权shell脚本并正确配置JAVA_HOME指向JDK根目录，启用manager需修改tomcat-users.xml并重启。
下载哪个版本的 apache-tomcat 才不踩坑
Java 17+ 项目别用 Tomcat 9，它只支持到 Java 11；Tomcat 10.1.x 是当前最稳的选择，原生支持 Jakarta EE 9+（即 jakarta.servlet.* 包名），但如果你还在用 javax.servlet.* 的老代码，要么降级到 Tomcat 9.0.85+（有 backport 补丁），要么批量替换包名——后者更可持续。
Windows 用户直接下 zip 包，别装 exe 安装版：它会静默注册 Windows 服务、改注册表、绑本地 8080 端口，后续调试时端口冲突都找不到源头。
-
Tomcat 10.1.x→ 对应 JDK 11/17/21，要求servlet-api依赖用jakarta.servlet-api -
Tomcat 9.0.85+→ 兼容 JDK 8–17，仍用javax.servlet-api，适合迁移过渡 - Mac/Linux 用户解压后务必检查
bin/startup.sh和bin/catalina.sh的执行权限：chmod +x bin/*.sh
JAVA_HOME 没设对，catalina.sh 启动就报 Neither the JAVA_HOME nor the JRE_HOME environment variable is defined
Tomcat 不读 PATH，只认 JAVA_HOME（指向 JDK 根目录）或 JRE_HOME（指向 JRE 根目录）。常见错误是把 JAVA_HOME 设成 /usr/lib/jvm/java-17-openjdk-amd64/bin ——尾巴多了一个 /bin，实际该设为 /usr/lib/jvm/java-17-openjdk-amd64。
验证方式很简单，在终端运行：echo $JAVA_HOME，再跟 java -version 输出的版本比对。不一致？立刻重设。
- 临时生效（当前终端）：
export JAVA_HOME=/path/to/jdk-17 - 永久生效（Linux/macOS）：加到
~/.bashrc或~/.zshrc；Windows 加系统环境变量，**不要加在用户变量里**（Tomcat 服务模式下可能读不到） - 如果用 IDE（如 IntelliJ）启动 Tomcat，记得在 Run Configuration → Environment Variables 里显式传入
JAVA_HOME
启动后访问 http://localhost:8080 显示 404，不是配置错了，是默认没开管理页面
Tomecat 10.1+ 默认禁用 manager 和 host-manager 应用，首页只剩一个静态欢迎页。这不是部署失败，是安全策略——你得手动启用。
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
关键操作在 conf/tomcat-users.xml：添加角色和用户，再在 webapps/ 下确认对应 WAR 包存在（manager.war 和 host-manager.war 通常自带）。
- 编辑
conf/tomcat-users.xml，在<role rolename="manager-gui"></role><role rolename="host-manager-gui"></role><user username="admin" password="s3cr3t" roles="manager-gui,host-manager-gui"></user>
- 重启 Tomcat，再访问
http://localhost:8080/manager/html就能上传 WAR 包了 - 注意：生产环境绝不能用这种明文密码 + 开放 manager 页面；开发机也建议绑定
localhost（改conf/server.xml中address="127.0.0.1"）
IDE 集成 Tomcat 后热部署失效，WEB-INF/classes 改了也不刷新
IntelliJ 或 Eclipse 默认用「exploded」模式部署，但 Tomcat 自身的自动扫描（reloadable="true"）在 IDE 集成场景下常被绕过。根本原因不是配置漏了，而是 IDE 把 class 文件输出到了非标准路径，Tomcat 根本没监听那个目录。
以 IntelliJ 为例：进 Project Structure → Modules → Paths，确认 Output path 指向的是 out/artifacts/xxx_war_exploded/WEB-INF/classes，而不是默认的 out/production/xxx。
- 在
conf/context.xml里确保 - 避免用 Maven 的
tomcat7-maven-plugin等旧插件——它们和现代 Tomcat 10+ 的类加载机制冲突 - 真正可靠的热更新方式是：IDE 触发「Build → Build Project」后，手动点 Tomcat 控制台的「Redeploy」按钮，别依赖自动扫描
Tomcat 的配置项看着不多，但每个都卡在 Java 类路径、JVM 启动参数、Web 容器生命周期三个层面之间。最容易被忽略的是：你以为改了 server.xml 就生效，其实很多设置（比如最大线程数、编码）得同步改 bin/catalina.sh 里的 JAVA_OPTS。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
