Tomcat的处理web.xml里有一行配置，决定了.jsp结尾的为问请URL到底交给谁处理。很多人以为是扩展Tomcat自己硬编码的，其实不是处理——它靠的是Servlet映射规则。你打开conf/web.xml，为问请能找到这么一段：

<servlet-mapping> <servlet-name>jsp</servlet-name> <url-pattern>*.jsp</url-pattern> </servlet-mapping>

这就是扩展答案的核心。凡是处理URL路径以.jsp结尾的请求，Tomcat会交给名为jsp的为问请那个Servlet去处理。这个Servlet类是扩展org.apache.jasper.servlet.JspServlet，属于Jasper模块——Tomcat的处理JSP引擎。

但光知道这个还不够。为问请真正有意思的扩展是JspServlet拿到请求之后干了什么。

第一次访问和第二次访问，处理走的为问请路完全不同

你写了一个hello.jsp，浏览器第一次请求它。扩展JspServlet收到请求后，先去检查这个JSP文件有没有被编译过。没有。于是它把hello.jsp翻译成一个Java源文件，通常放在Tomcat的work目录下，比如work/Catalina/localhost/你的应用名/org/apache/jsp/hello_jsp.java。翻译完之后调用JDK的编译器把它编译成.class文件。然后加载这个类，实例化，执行_jspService()方法，把生成的HTML写回response。

第二次请求同一个hello.jsp，JspServlet发现已经编译过了，而且JSP源文件的最后修改时间没有变化，那就跳过翻译和编译，直接执行之前加载的Servlet实例。速度快很多。

这个机制有个常见的坑：你在生产环境改了JSP文件，如果没触发重新编译的条件（比如某些容器配置了development=false），页面可能还是旧的。我遇到过一回，运维改了JSP上的一个文案，刷新半天没变化，最后发现是work目录下的class文件没重新生成。删掉work目录下的缓存，重启，问题消失。

为什么不是所有请求都归JspServlet管

因为url-pattern写的是*.jsp，这是扩展名匹配。Servlet规范里，URL映射有优先级：精确匹配 > 路径匹配 > 扩展名匹配 > 默认匹配。所以如果你在web.xml里自己定义了一个servlet-mapping，精确匹配到/hello.jsp这个路径，那它就会覆盖掉Tomcat默认的*.jsp规则。你的Servlet来处理，JspServlet靠边站。

这种操作在实际项目里不常见，但有人用它来做JSP请求的拦截或改写。比如把所有.jsp请求先路由到一个自定义Servlet做权限校验，通过了再forward到真正的JSP。不过现在前后端分离的项目多了，JSP本身用得少了，这类需求也跟着少了。

JspServlet和DefaultServlet的关系

顺带说一个容易混淆的点。静态资源比如.html、.css、.js，Tomcat默认交给DefaultServlet处理。而.jsp交给JspServlet。两个Servlet各管一摊。你在web.xml里能看到DefaultServlet的映射是/，这是默认匹配，优先级最低。所以一个请求过来，Tomcat先看有没有精确匹配，再看路径匹配，再看扩展名匹配，最后才落到DefaultServlet头上。

*.jsp是扩展名匹配，优先级高于默认匹配。所以.jsp请求不会跑到DefaultServlet那里去。这个顺序搞清楚了，很多“为什么我的请求走到了意料之外的Servlet”的问题就迎刃而解了。

说到底，处理.jsp URL请求的是JspServlet，它做的是翻译、编译、执行这三件事。理解了这个链条，排查JSP相关问题时心里就有谱了——去看work目录、去看web.xml的映射、去看JSP文件的修改时间，基本能定位到大部分毛病。