JSP运行原理深度解析：从Servlet到动态网页的完整生命周期

1. 从静态HTML到动态JSP：一个老兵的视角

如果你在2000年代初期开始接触Java Web开发，那么JSP（JavaServer Pages）对你来说，可能就像一位熟悉的老朋友，或者是一段绕不开的“历史债务”。今天，我想从一个经历过那个时代的老兵视角，和你聊聊JSP到底是什么，以及它究竟是怎么跑起来的。这不仅仅是技术概念的罗列，更是理解一个时代技术选型背后逻辑的钥匙。

简单来说，JSP是一种用于创建动态Web内容的技术。它允许你将Java代码直接嵌入到HTML页面中。当用户请求一个.jsp文件时，服务器（比如Tomcat）会先执行其中的Java代码，然后将生成的HTML结果发送给浏览器。所以，你看到的最终页面，是“计算”出来的，而不是一个写死的静态文件。它的核心价值在于，让熟悉Java但不一定精通前端复杂交互的开发者，能够相对轻松地生成动态网页。在Servlet（纯Java类处理HTTP请求）和纯HTML之间，JSP找到了一个平衡点：用类HTML的语法写页面，用<% %>标签写逻辑。

2. JSP的本质：它不是什么，以及它到底是什么

在深入原理之前，我们先要破除几个常见的误解。很多人，尤其是刚入门的朋友，容易把JSP和JavaScript、或者和纯粹的HTML模板引擎混为一谈。

JSP不是JavaScript。这是最容易混淆的一点。JavaScript（JS）是运行在浏览器端的脚本语言，用于实现页面的动态交互效果，比如表单验证、动画等。而JSP是运行在服务器端的技术。你在JSP页面里写的Java代码，在页面离开服务器、到达用户浏览器之前，就已经执行完毕了。浏览器收到的，只是JSP执行后生成的纯HTML、CSS和JS代码。所以，一个.jsp文件里，可以同时包含服务端的Java逻辑（<% ... %>）和客户端的JavaScript代码（<script>...</script>），它们在不同的地方、不同的时间运行。

JSP也不仅仅是“HTML里写Java”。这种说法虽然形象，但过于简化。更准确地说，JSP是一种基于文本的文档，它知道如何将自己转化为一个Servlet。是的，JSP的最终形态，就是一个Java类，一个特殊的Servlet。这是理解其运行原理的基石。

那么，JSP到底是什么？我们可以从几个层面来看：

1. 技术规范：它是Java EE（现Jakarta EE）规范的一部分，定义了如何将动态内容嵌入到静态模板中。
2. 服务器端组件：它是一个运行在Web容器（如Tomcat, TongWeb）中的组件，用于动态生成响应。
3. 模板技术：它是一种早期的、将表现层（HTML）和业务逻辑层（Java代码）混合的模板技术。虽然这种混合在后来的MVC模式中被视为不够优雅，但在其诞生之初，极大地提升了开发效率。

它的核心组成部分包括：

• 模板文本：就是普通的HTML、CSS、JavaScript代码，这部分会原样输出到响应中。
• JSP元素：这是JSP的“魔法”所在，主要有三种类型：
  • 脚本元素：<% %>用于嵌入Java代码片段；<%= %>用于输出表达式的结果；<%! %>用于声明成员变量和方法。
  • 指令：以<%@ %>表示，用于给整个页面设置属性，比如引入Java类（<%@ page import="java.util.*" %>）、包含其他文件（<%@ include file="header.jsp" %>）、使用标签库（<%@ taglib %>）。
  • 动作：以<jsp:xxx >表示，提供了一些标准操作，如转发请求（<jsp:forward>）、包含动态内容（<jsp:include>）、使用JavaBean（<jsp:useBean>）。

3. JSP的运行原理：从.jsp文件到浏览器响应的完整旅程

理解了JSP的本质是Servlet的“源代码”，我们就能清晰地描绘出它的运行轨迹。这个过程不是一蹴而就的，而是包含了关键的“翻译”和“编译”步骤。下面，我们结合Tomcat这个最常用的容器，来一步步拆解。

3.1 旅程的起点：客户端请求

当用户在浏览器地址栏输入http://localhost:8080/yourApp/index.jsp并按下回车时，旅程就开始了。这个请求通过网络到达部署了你的Web应用的Tomcat服务器。

3.2 容器的接收与映射

Tomcat作为一个Servlet容器，它的核心工作之一是管理URL到具体处理资源的映射。它内部维护着一个映射表。当收到对.jsp后缀的请求时，Tomcat不会直接去找一个叫index.jsp的文件来读取并返回。相反，它被一个特殊的Servlet——JspServlet所拦截。

这个JspServlet是Tomcat内置的，专门负责处理所有.jsp请求。你可以把它想象成JSP的“总调度员”和“编译器”。

3.3 核心阶段：翻译与编译

这是JSP运行原理中最关键、也最容易被忽略的一步。JspServlet接到请求后，会检查请求的JSP文件（例如index.jsp）。

1. 检查编译状态：首先，它会去检查工作目录（通常是Tomcat/work/Catalina/localhost/yourApp/）下，是否已经存在这个JSP文件对应的Servlet Java源文件（.java）和编译后的类文件（.class）。
2. 翻译（Translation）：如果这是该JSP文件第一次被访问，或者JSP文件在上次访问后被修改过，JspServlet就会启动翻译过程。它会读取index.jsp的文本内容，然后进行复杂的解析：
   • 将所有的模板文本（HTML）转换为out.write(“...”);这样的输出语句。
   • 将<% %>中的Java代码原样嵌入到生成的服务方法（如_jspService）中。
   • 将<%= %>表达式转换为out.print(...);。
   • 处理<%@ page %>,<%@ include %>等指令。
   • 最终，生成一个完整的、符合Java语法的.java源文件。这个文件是一个标准的Servlet类，通常继承自org.apache.jasper.runtime.HttpJspBase。生成的类名类似index_jsp.java。
3. 编译（Compilation）：.java源文件生成后，Tomcat会调用Java编译器（javac）将其编译成.class字节码文件。至此，你的index.jsp就完成了一次“华丽变身”，从一个文本文件变成了一个可执行的Java类。

注意：这个“首次访问编译”机制，就是为什么第一次打开一个JSP页面时感觉特别慢的原因。后续的请求会直接调用已经编译好的.class文件，速度就快多了。这也是生产环境中，经常进行“预热”操作（提前访问一遍所有JSP页面）的原因。

3.4 执行与响应

一旦对应的index_jsp.class存在且是最新的，Tomcat就会加载这个类，并创建其实例（实际上，Servlet通常是单例多线程的，但理解成每次请求对应一个执行线程即可）。

然后，Tomcat容器会调用该Servlet的_jspService(HttpServletRequest request, HttpServletResponse response)方法。这个方法就是由JSP页面内容翻译而来的核心方法。在这个方法内部：

• 预定义的out对象（JspWriter）开始工作。
• 你的Java业务逻辑代码被执行。
• HTML模板文本通过out.write()输出。
• 动态数据被计算并插入到输出流中。

所有这一切都发生在服务器内存里。最终，_jspService方法执行完毕，一个完整的、纯静态的HTML（或其它格式）响应流就生成了。

3.5 旅程的终点：客户端渲染

Tomcat将这个生成的HTML响应流通过HTTP协议发送回发起请求的浏览器。浏览器接收到这个响应后，完全不知道它曾经是一个.jsp文件，它只看到一个标准的HTML文档，于是开始解析HTML、加载CSS/JS、渲染页面。对浏览器而言，整个过程与请求一个静态.html文件没有区别。

整个过程可以简单总结为：JSP文件 -> (首次请求) -> JspServlet翻译成Java源文件 -> 编译成Servlet类 -> 执行Servlet的_jspService方法 -> 生成纯HTML响应 -> 发送给浏览器。

4. 为何需要理解原理：从配置排错到技术选型

知道了JSP怎么运行，绝不仅仅是为了应付面试。它在实际开发和运维中，能帮你解决很多实实在在的问题。

4.1 破解经典错误：“JSP is missing from the classpath”

如果你在尝试运行一个Web应用时，遇到了类似“tongweb jsp is missing from the classpath, which is required for tongweb at...”或“The absolute uri: [http://java.sun.com/jsp/jstl/core] cannot be resolved...”这样的错误，现在你就能看懂了。

这通常意味着，你的Web容器（无论是Tomcat、TongWeb还是其它）在它的类路径（classpath）中找不到处理JSP所必须的库文件，比如jasper.jar（Tomcat的JSP引擎实现）或者JSTL标签库的jar包。因为JSP的翻译和编译工作是由容器特定的模块完成的，缺少这些模块，JspServlet就无法正常工作。

解决方案：

• 对于Tomcat：确保你的Tomcatlib目录下包含jasper.jar,jsp-api.jar等文件。如果是部署到独立的Tomcat，这些jar包通常已存在。如果是在IDE（如IDEA、VSCode）中运行，需要检查IDE集成的Tomcat组件是否完整，或者构建路径（Build Path）/ 项目依赖中是否引入了这些库。
• 对于嵌入式容器（如Spring Boot）：Spring Boot默认使用嵌入式Tomcat，但为了减小打包体积，它可能不会默认包含JSP支持。你需要在pom.xml或build.gradle中显式添加对Tomcat Jasper的依赖。

  <!-- Maven 示例：Spring Boot中启用JSP支持 --> <dependency> <groupId>org.apache.tomcat.embed</groupId> <artifactId>tomcat-embed-jasper</artifactId> <scope>provided</scope> </dependency>

• 对于JSTL错误：你需要将jstl.jar和standard.jar（或新的如jakarta.servlet.jsp.jstl-api）放到项目的WEB-INF/lib目录下，或通过Maven/Gradle引入。

4.2 理解部署与“两个Tomcat”的Session之谜

有这样一个搜索热词：“两个tomcat部署两个相同的项目,在浏览器中登录一个时,另一个项目的session过期”。这听起来很诡异，但结合JSP/Servlet原理就能理解。

Session（会话）是服务器端用来跟踪用户状态的一种机制。默认情况下，Tomcat使用JSESSIONID这个Cookie来关联Session。关键点在于：Session是由具体的Web应用上下文（Context）在服务器内存中创建的。

如果你在两个不同的Tomcat实例（甚至是同一台机器上的两个不同端口）上部署了完全相同的项目（相同的上下文路径，比如都是/myapp），那么对于浏览器来说，它访问的是两个不同的“网站”（不同端口）。虽然项目代码一样，但它们的Session存储空间是隔离的。你在Tomcat A的/myapp中登录创建的Session，存储在Tomcat A的内存里；Tomcat B对此一无所知。

但是，如果浏览器因为某种原因（比如旧的Cookie未清除）在访问Tomcat B的应用时，携带了之前在Tomcat A获得的JSESSIONID，Tomcat B会在自己的内存空间里查找这个ID对应的Session。显然找不到，它可能就会将这个Session视为“无效”或“过期”，从而导致用户需要重新登录。这并非真正的“过期”，而是Session ID跨服务器实例不匹配造成的。

解决方案：

• 使用负载均衡器：在生产环境中，多个Tomcat实例前应配置负载均衡器（如Nginx），并启用Session粘滞（Sticky Session），确保同一用户的请求总是转发到同一个Tomcat实例。
• 集中式Session管理：将Session存储从单个Tomcat的内存中移出，放到集中式的存储中，如Redis、数据库或专门的Session服务器（如Apache Ignite）。这样所有Tomcat实例都能访问到同一个Session存储，问题自然解决。Spring Session项目就提供了这样的能力。

4.3 技术演进与当代定位：JSP过时了吗？

这是一个不可避免的问题。随着前后端分离架构（React, Vue, Angular + Spring Boot API）的盛行，以及更现代化的服务器端模板引擎（Thymeleaf, FreeMarker）的出现，JSP在新技术项目中的使用率确实在下降。

JSP的局限性：

• 前后端耦合：JSP混合了Java和HTML，不利于前后端职责分离，也不利于前端工程师独立工作。
• 测试困难：由于视图和逻辑混杂，对JSP页面进行单元测试比较麻烦。
• 性能依赖：首次编译需要时间，虽然可预热，但在动态伸缩的云环境中，新实例启动时仍可能带来延迟。
• 功能相对单一：相较于现代前端框架，其动态交互能力较弱，重度依赖页面刷新或配合Ajax。

但是，JSP远未“死亡”：

• 遗留系统维护：大量的传统企业级应用（银行、电信、政府系统）仍然基于JSP/Struts/Spring MVC构建，维护这些系统需要深入理解JSP。
• 快速原型与内部工具：对于需要快速产出简单管理后台、内部报表页面的场景，JSP配合Bootstrap等前端库，依然非常高效。
• 学习价值：理解JSP是理解Java Web开发演进史的重要一环。它清晰地展示了从Servlet到MVC框架（如Spring MVC的@Controller返回视图名）的过渡逻辑。很多现代模板引擎的思想也与之有相通之处。

我的建议是：对于新手，仍然有必要学习JSP的基本原理，因为它揭示了Web开发中“动态内容生成”的核心模型。但对于新项目启动，除非有非常特殊的约束（如必须使用特定旧框架），否则更推荐采用前后端分离架构或使用Thymeleaf这类更纯粹、功能更强的模板引擎。

5. 动手实践：搭建一个最简单的JSP环境

理解了原理，我们亲手搭一个环境，写一个简单的JSP页面，感受一下整个过程。这里以最经典的Tomcat + 手动部署为例。

5.1 环境准备

1. 安装JDK：确保已安装Java Development Kit (JDK 8或以上)，并配置好JAVA_HOME环境变量。
2. 下载并解压Tomcat：从Apache官网下载Tomcat（如9.x版本），解压到任意目录，例如D:\apache-tomcat-9.0.xx。这就是你的Tomcat根目录（CATALINA_HOME）。

5.2 创建Web应用结构

在Tomcat的webapps目录下，创建一个新的文件夹，这就是你的Web应用根目录，例如myfirstjsp。

在myfirstjsp文件夹内，创建标准的Java Web应用目录结构：

myfirstjsp/ │ ├── WEB-INF/ │ ├── web.xml (部署描述符，Tomcat 10/Servlet 5.0+ 可省略) │ └── classes/ (存放编译后的Java类，可选) │ └── lib/ (存放第三方jar包，可选) │ └── index.jsp (我们的第一个JSP页面)

5.3 编写第一个JSP页面

用文本编辑器（Notepad++, VSCode等）创建index.jsp文件，内容如下：

<%@ page contentType="text/html;charset=UTF-8" language="java" %> <%@ page import="java.util.Date" %> <!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8"> <title>我的第一个JSP页面</title> </head> <body> <h1>Hello JSP World!</h1> <p>现在的时间是：<%= new Date() %></p> <p>你的IP地址是：<%= request.getRemoteAddr() %></p> <% // 这是一段Java脚本片段 int count = 0; // 尝试从application作用域获取计数器 Object obj = application.getAttribute("visitCount"); if (obj != null) { count = (Integer) obj; } count++; application.setAttribute("visitCount", count); %> <p>本页面已被访问 <strong><%= count %></strong> 次。</p> <form action="greet.jsp" method="get"> 请输入你的名字：<input type="text" name="username"> <input type="submit" value="打招呼"> </form> </body> </html>

再创建一个greet.jsp来处理表单：

<%@ page contentType="text/html;charset=UTF-8" language="java" %> <!DOCTYPE html> <html> <head><title>打招呼</title></head> <body> <% String name = request.getParameter("username"); if (name == null || name.trim().isEmpty()) { name = "匿名朋友"; } %> <h2>你好，<%= name %>！</h2> <a href="index.jsp">返回首页</a> </body> </html>

5.4 启动Tomcat并访问

1. 打开命令行，进入Tomcat的bin目录。
2. 执行启动脚本：
   • Windows:catalina.bat run或直接双击startup.bat
   • Linux/macOS:./catalina.sh run
3. 观察控制台输出，直到看到Server startup in [xxxx] milliseconds。
4. 打开浏览器，访问http://localhost:8080/myfirstjsp/index.jsp。

此时，神奇的事情发生了：

• 第一次访问时，你会注意到浏览器状态栏会等待一会儿，同时Tomcat控制台会有JSP编译相关的日志输出。这就是我们前面讲的“翻译与编译”过程。
• 页面上会显示当前时间、你的IP地址和一个访问计数器。刷新页面，计数器会增加。
• 输入名字提交后，会跳转到greet.jsp并显示问候语。

你可以去Tomcat的work/Catalina/localhost/myfirstjsp/org/apache/jsp目录下看看，会发现生成了index_jsp.java和index_jsp.class等文件。打开index_jsp.java，你会看到你写的HTML和Java代码都被转换成了Servlet代码，这就是JSP的“真身”。

6. 与Servlet的共生关系：为什么是JSP而不是纯Servlet

在JSP出现之前，开发动态Web页面的主要方式是使用Servlet。在Servlet里，你需要用out.println(“<html>…”);的方式，一行行地拼接HTML字符串。这对于生成复杂页面来说，简直是程序员的噩梦——代码难以编写、阅读和维护，更别提让前端设计师参与了。

JSP的出现，本质上是为了弥补Servlet在表现层输出上的短板。它做了一个角色反转：

• Servlet 擅长控制逻辑：处理请求参数、调用业务服务、控制流程（转发、重定向）。它更像一个“控制器”。
• JSP 擅长展示页面：利用类HTML的语法，方便地编排页面布局、嵌入动态数据。它更像一个“视图”。

于是，经典的Model 1和Model 2 (MVC)模式就形成了：

• Model 1：JSP页面同时承担控制器和视图的角色，直接处理请求和访问数据库。结构简单，适合小型应用，但逻辑和视图混杂，难以维护。
• Model 2 (MVC)：这是更优的实践。Servlet作为控制器（Controller），接收请求，处理业务逻辑，将结果数据放入请求作用域（request.setAttribute），然后转发（request.getRequestDispatcher(“xxx.jsp”).forward(...)）到JSP视图（View）。JSP只负责从作用域中取出数据并渲染展示。模型（Model）则由普通的Java Bean或业务类来承担。

// 一个简单的Model 2 Servlet示例 @WebServlet("/userList") public class UserListServlet extends HttpServlet { protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { // 1. 调用业务层，获取数据（Model） List<User> userList = userService.getAllUsers(); // 2. 将数据存入请求作用域，传递给JSP request.setAttribute("users", userList); // 3. 转发到JSP页面进行展示（View） request.getRequestDispatcher("/WEB-INF/views/userList.jsp").forward(request, response); } }

在对应的userList.jsp中，你可以使用JSTL或EL表达式来优雅地展示数据，而不需要写<% %>脚本：

<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %> <table> <c:forEach var="user" items="${users}"> <tr><td>${user.name}</td><td>${user.email}</td></tr> </c:forEach> </table>

这种模式清晰地将职责分离，也是后来Spring MVC等框架所遵循的核心思想。所以，JSP从来不是要取代Servlet，而是与它协同工作，共同构建完整的Java Web应用。

7. 深入细节：JSP的九大隐式对象与作用域

在JSP页面中，你可以直接使用一些对象，如request,response,out,session，而无需声明。这些就是JSP的隐式对象，它们由容器在翻译JSP为Servlet时自动生成并注入到_jspService方法中。理解它们至关重要。

1. request (HttpServletRequest): 代表客户端的HTTP请求，包含了所有请求参数、头信息等。
2. response (HttpServletResponse): 代表对客户端的HTTP响应，用于设置头信息、状态码，获取输出流等。
3. out (JspWriter): 用于向客户端输出内容的字符流。它和response.getWriter()类似，但经过缓冲，更适合在JSP中使用。
4. session (HttpSession): 代表与某个用户关联的会话。用于存储用户级别的数据，如登录信息。
5. application (ServletContext): 代表整个Web应用。用于存储应用级别的全局数据，生命周期从应用启动到关闭。
6. pageContext (PageContext): 这是最重要的对象之一。它提供了访问所有其他隐式对象、管理属性作用域的方法。例如，pageContext.setAttribute(“key”, value, PageContext.REQUEST_SCOPE)。
7. page (Object): 相当于Java中的this，指向当前JSP页面转换后的Servlet实例本身，一般很少直接用。
8. config (ServletConfig): 代表当前JSP页面的Servlet配置信息。
9. exception (Throwable): 只有在声明了<%@ page isErrorPage=”true” %>的错误处理页面中，这个对象才可用，指向引发错误的异常。

与这些对象紧密相关的是四大作用域，它们决定了你设置的属性（setAttribute）在哪里有效：

• page 作用域：属性仅在当前JSP页面内有效。通过pageContext.setAttribute(“name”, value)设置。
• request 作用域：属性在一次HTTP请求范围内有效，包括请求转发（forward）到的其他JSP或Servlet。通过request.setAttribute(“name”, value)设置。这是MVC中控制器向视图传递数据的主要方式。
• session 作用域：属性在一次用户会话（浏览器打开到关闭，或会话超时）内有效。通过session.setAttribute(“name”, value)设置。常用于存储用户登录状态、购物车等。
• application 作用域：属性在整个Web应用生命周期内对所有用户都有效。通过application.setAttribute(“name”, value)设置。常用于存储全局配置、缓存等。

选择哪个作用域？一个基本原则是：使用能满足需求的最小作用域。能用request解决的，就不要用session；能用session解决的，就不要用application。滥用大作用域（尤其是application）会浪费服务器内存，并可能引发线程安全问题。

8. 现代开发中的JSP：最佳实践与避坑指南

即使在今天维护老项目或特定场景下使用JSP，遵循一些最佳实践也能让代码更健壮、更易维护。

8.1 脚本 vs 标签 vs EL表达式

早期JSP中充斥着<% %>脚本，这被戏称为“意大利面条式代码”，极难维护。现代JSP开发应遵循以下优先级：

1. 首选 EL 表达式${}：用于简单地从作用域（page, request, session, application）中输出数据或进行简单运算。它简洁、安全（默认会进行HTML转义，防止XSS攻击），且易于阅读。

   • 好：<p>Welcome, ${user.name}!</p>
   • 不好：<p>Welcome, <%= request.getAttribute(“user”).getName() %>!</p>

2. 善用 JSTL 标签库：对于循环、条件判断、格式化等逻辑，坚决使用JSTL标签代替Java脚本。

   • 核心标签库 (c)：<c:if>,<c:forEach>,<c:choose>,<c:set>等。
   • 格式化标签库 (fmt)：<fmt:formatDate>,<fmt:formatNumber>等。
   • 函数标签库 (fn)：${fn:length(list)},${fn:contains(string, substr)}等。
   • 使用JSTL能让JSP页面看起来更像一个纯粹的视图模板，几乎看不到Java代码。

3. 尽量避免/淘汰<% %>脚本：在新的开发中，应禁止使用。在老项目维护中，应有计划地将脚本逻辑迁移到Servlet控制器或后台服务中，JSP页面只负责显示。

8.2 常见的“坑”与解决方案

• 中文乱码问题：这是JSP新手最常遇到的问题。

  • 根源：请求/响应编码、页面文件存储编码、数据库编码不一致。
  • 解决方案：
    1. 确保JSP文件本身以UTF-8编码保存（在IDE中设置）。
    2. 在每个JSP页面顶部添加：<%@ page contentType=”text/html;charset=UTF-8” language=”java” pageEncoding=”UTF-8”%>。
    3. 对于POST请求，在获取参数前设置请求编码：request.setCharacterEncoding(“UTF-8”);（通常在过滤器中统一设置）。
    4. 在Servlet中设置响应编码：response.setContentType(“text/html;charset=UTF-8”);。
    5. 配置Tomcat的server.xml中Connector的URIEncoding=”UTF-8″以处理GET请求URL中的中文。

• JSP页面被直接显示源代码：访问.jsp文件，浏览器却显示其代码文本。

  • 原因：Tomcat没有正确识别并处理.jsp请求。可能的原因包括：Tomcat的JSP引擎（Jasper）未启动或损坏；应用被部署到了静态资源目录；web.xml中配置了错误的Servlet映射。
  • 排查：检查Tomcat日志；确认应用是否部署在webapps下或配置了正确的Context；检查conf/web.xml中确保对*.jsp的映射是由JspServlet处理的。

• 性能问题：首次访问慢，或修改后访问慢。

  • 首次访问慢：这是编译开销，生产环境可通过“预热”解决（写一个脚本在启动后访问所有关键JSP页面）。
  • 修改后访问慢：Tomcat默认会检查JSP文件是否更新。你可以调整conf/web.xml中JspServlet的初始化参数，如development设为false以关闭运行时检查，但这样修改JSP后需要重启应用或手动清除work目录下的编译文件才能生效，一般不建议在生产环境修改。

• “重复的JSP”问题：在IDE中，有时会遇到一个JSP文件在两个地方被编译，导致类冲突。

  • 场景：你使用IDEA或Eclipse，将项目部署到外置Tomcat，同时IDE又用自己的机制编译了JSP。
  • 解决：理解IDE的部署机制。通常，你需要将“项目输出目录”或“编译后的类目录”指向Tomcat的webapps/yourapp/WEB-INF/classes，并确保“发布”设置正确，避免IDE和Tomcat各自为政。

JSP作为Java Web开发历史上一个里程碑式的技术，它的设计思想——将动态逻辑嵌入静态模板——影响深远。虽然在新项目的技术选型中，它可能不再是首选，但深入理解其运行原理、核心对象和最佳实践，对于维护浩如烟海的遗留系统、深刻理解Web请求处理流程，乃至学习后续更先进的框架，都有着不可替代的价值。它更像是一本活的教科书，记载了Web开发从混合到分离的演进之路。当你下次再遇到一个JSP页面时，希望你能透过那些<% %>标签，看到背后那个辛勤工作的JspServlet和它生成的Servlet类，这才是解决问题的根本。