JSP在WEB服务器上运行结果

把 hello.jsp 丢进 Tomcat 的 webapps/ROOT 目录，启动服务器，器上浏览器敲下 http://localhost:8080/hello.jsp，运行回车。结果屏幕上蹦出“Hello,服务 JSP!”——这行字不是静态的，它背后经历了一次完整的器上翻译、编译、运行执行。结果你看到的服务是结果，服务器干的器上是脏活累活。

第一次请求某个 JSP 页面时，运行Tomcat 会把它翻译成一个 Java 源文件（比如 hello_jsp.java），结果然后调用 JDK 编译器把它编译成 .class 字节码。服务这个过程有延迟，器上通常几百毫秒到一两秒。运行之后再次访问同一页面，服务器直接执行已经编译好的 Servlet 类，响应速度跟普通 Servlet 没区别。很多人以为 JSP 是“解释执行”，其实它是“编译执行”。

那运行结果到底长什么样？分几种情况。最普通的是纯 HTML 输出——JSP 里的模板文本原样发给浏览器，<% %> 里的 Java 代码在服务器端跑完，把结果插入到输出流。浏览器查看源代码，只能看到最终生成的 HTML，看不到一行 Java。这是 JSP 的基本形态。

如果 JSP 里用了 out.println() 或者表达式 <%= new java.util.Date() %>，服务器会把日期字符串拼进 HTML 里。浏览器收到的是类似 <p>Mon Apr 07 15:30:22 CST 2025</p> 这种东西。每次刷新，时间都在变。这说明代码在服务器端执行了，而不是浏览器端。

错误也是运行结果的一部分。比如你写 <% int x = 1/0; %>，服务器不会把除零异常直接发给浏览器。Tomcat 会捕获它，返回一个 500 错误页面，同时把堆栈信息写进日志文件。你看到的可能是“HTTP Status 500 – Internal Server Error”，底下跟着一段异常描述。开发阶段这很烦，但生产环境得关掉详细错误页，换成自定义的错误 JSP。

还有一种情况容易被忽略：JSP 被编译成 Servlet 后，_jspService() 方法里会生成大量 out.write() 调用。如果页面里有大量静态 HTML，Tomcat 会优化成一次性写入字符数组。结果就是响应体里 HTML 和动态内容混在一起，顺序完全取决于代码位置。有人把 <% %> 写在 <html> 标签之前，结果输出流里先出现了动态内容，再出现 <!DOCTYPE html>，浏览器直接进入怪异模式。这不是服务器的问题，是写 JSP 的人没搞清楚输出顺序。

缓存也会影响运行结果。浏览器可能缓存了之前的 JSP 输出，你改了代码重启 Tomcat，刷新页面还是旧内容。按 Ctrl+F5 强制刷新才看到新的。服务器端也有缓存——JSP 编译后的 Servlet 类默认不会自动重新加载，除非你配置了 development 模式或者手动删除 work 目录。我见过有人改了 JSP 死活不生效，最后发现是 Tomcat 的 work 目录里还躺着旧的 .class 文件。

补充一个细节：JSP 里的 session 对象默认是开启的。如果你在页面里写 <%= session.getId() %>，每次请求同一个浏览器会话，输出的 JSESSIONID 都一样。换一个浏览器或者清掉 cookie，ID 就变了。这个结果直接反映了服务器端的会话管理机制。

最后说一个反直觉的现象。JSP 页面里写 <% response.setHeader("X-Test", "abc"); %>，但这一行前面已经有 HTML 输出了，比如 <html> 标签。那么设置响应头的代码会抛 IllegalStateException，因为响应已经提交了。运行结果就是页面显示一半，然后报错。JSP 的缓冲区默认 8KB，超出就自动 flush，之后就不能再改响应头了。这个坑我踩过好几次。

所以，JSP 在 Web 服务器上的运行结果，不是“一个页面”那么简单。它是翻译、编译、执行、缓冲、会话、错误处理共同作用的产物。你看到的 HTML 只是冰山一角，水面下是 Servlet 容器在拼命干活。