Tomcat返回500状态码，状态本质上是内部服务器端Java代码抛出了未捕获的异常。这个数字本身不携带任何具体错误信息，服务它更像一个“出事了”的器错粗鲁通知。

你访问一个JSP页面，意思页面里调用了数据库，状态但数据库连接池刚好满了。内部Tomcat后台会打印完整的服务堆栈跟踪，但浏览器里只有苍白的器错“500”。这是意思最典型的场景。

另一个高频原因藏在web.xml里。状态Servlet初始化时如果抛异常，内部或者过滤器链中某个环节出了问题，服务Tomcat会直接拒绝整个请求。器错我见过一个项目，意思因为一个过滤器里写了错误的编码转换逻辑，导致所有POST请求全部500，而GET请求正常——排查时很容易被误导去查数据库。

还有种情况更隐蔽：JSP页面编译失败。Tomcat运行时会动态把JSP翻译成Java类，如果页面里有语法错误或者引用了不存在的类，第一次访问就会触发500。第二次访问可能还是500，但错误信息已经变了——第一次是编译错误，第二次是类加载失败。

配置文件也是重灾区。server.xml里如果端口被占用，Tomcat启动就会失败，但如果你用的是IDE内置的Tomcat，它可能显示“已启动”，实际访问时给你500。这种错位最让人抓狂。

想快速定位？打开Tomcat的logs目录，找到localhost.当天日期.log文件。里面会写清楚异常类型和具体行号。没有这个文件的话，去catalina.out里搜“SEVERE”关键字，基本能命中问题根源。

有个小技巧：如果错误发生在JSP页面本身，Tomcat会在响应体里附带部分堆栈信息——前提是你没在web.xml里自定义错误页面覆盖它。很多团队为了统一风格配置了，反而把最关键的调试信息藏起来了。调试阶段建议先注释掉那个配置。

最后说个反直觉的案例。有个系统偶尔500，重启Tomcat就好，几天后又犯。查到最后是内存泄漏——某个静态Map不断存数据，GC回收不掉，最终OutOfMemoryError。这种问题看日志只显示“无法分配内存”，但根因在代码里。所以500不总是代码逻辑错误，也可能是资源耗尽。

处理500的思路很简单：先看日志，再复现请求，最后检查资源状态。别在浏览器里反复刷新，那只会让日志刷屏，掩盖真正有用的信息。