Tomcat是轻量级Servlet/JSP容器，非通用Web服务器；支持动态资源处理但静态资源性能弱；需正确配置JAVA_HOME；部署方式有webapps、外部路径+XML、server.xml三类，后者应谨慎修改。
Tomcat 就是 Servlet 容器，不是通用 Web 服务器
它本质是一个运行 Java Web 应用的「Servlet/JSP 容器」，不是 Apache 或 Nginx 那种专为静态资源优化的 HTTP 服务器。你写一个 HttpServlet，Tomcat 负责加载、实例化、调用它的 doGet()/doPost()；你写一个 index.jsp，Tomcat 用 Jasper 引擎把它编译成 Servlet 再执行。它自带 HTTP 连接器（Connector），所以能直接响应浏览器请求，但性能和功能上不擅长处理大量图片、CSS、JS 等静态文件。
- 如果你只部署纯 Java Web 项目（含 JSP/Servlet），Tomcat 单独跑完全够用
- 如果项目混着大量前端资源（Vue 打包产物、React 静态页），建议前面加 Nginx 做反向代理和静态资源托管
- 它不支持完整的 Java EE 规范（比如 EJB、JMS），只实现 Servlet/JSP/EL/JSTL 等核心部分——这也是它轻量、启动快、调试方便的原因
为什么启动就闪退？大概率是 JAVA_HOME 没配对
Tomcat 是纯 Java 写的，bin/startup.bat（Windows）或 bin/startup.sh（Linux/macOS）第一件事就是找 JDK。如果系统里装了多个 JDK，或者只装了 JRE，或者 JAVA_HOME 指向的是 JRE 目录或错误路径，窗口就会一闪而逝，连日志都来不及输出。
- 检查方式：命令行执行
echo %JAVA_HOME%（Windows）或echo $JAVA_HOME（macOS/Linux），确认路径下有bin/java.exe（Windows）或bin/java（其他系统） - 正确值示例：
C:\Program Files\Java\jdk-17.0.2，而不是C:\Program Files\Java\jre1.8.0_301 - 验证是否生效：在终端运行
java -version和%JAVA_HOME%\bin\java -version（Windows）结果应一致
webapps 目录不是唯一部署方式，三种路径要分清
新手常以为把项目丢进 webapps 就完事，其实 Tomcat 提供了更灵活、更适合开发的部署方式，关键区别在于生命周期管理和热更新能力：
-
webapps/xxx.war：自动解压部署，适合生产环境；但修改 class 文件后需重启或重传 WAR，不便于调试 -
webapps/xxx/（解压目录）：可直接改 JSP、替换 class，但 Tomcat 默认会监控并可能触发 reload，导致 Session 丢失 - 外部路径 +
conf/Catalina/localhost/xxx.xml：最推荐开发用。例如在D:\myapp放项目，再新建conf/Catalina/localhost/myapp.xml，内容为：
这样改代码、JSP 都能热生效，且不影响其他应用
别把 server.xml 当万能配置文件乱改
很多人一遇到端口冲突、访问不了，就去猛改 conf/server.xml，结果引发更隐蔽的问题。它确实控制核心行为（如 Connector 端口、Engine 名称），但多数日常需求不该动它：
立即学习“Java免费学习笔记（深入）”；
- 改端口？优先查
netstat -ano | findstr :8080（Windows）看谁占了，而不是直接改成 8081——避免后续调试时忘了这茬 - 加虚拟主机？
Host配置容易和 DNS、本地hosts文件联动出错，开发阶段用不同 context path（如/app1、/app2）更安全 - 开远程管理界面？必须改
conf/tomcat-users.xml加角色（manager-gui），否则即使开了Manager应用也 403 ——这个细节被跳过的频率极高
Realm 认证和 Valve 过滤链），一旦在 server.xml 里嵌套错层级，或在 context.xml 里配了冲突的类加载器策略，问题往往不会立刻报错，而是表现为 Session 丢失、静态资源 404、甚至某些 Filter 不生效——这些都不是靠重启能解决的。 
