为什么JSP代码不能在浏览器直接运行？

直接双击 JSP 文件并不能得到动态渲染后的网页，浏览器要么将其作为纯文本原样展示并暴露后端的 Java 代码片段，要么直接提示下载文件。这是因为 JSP 是运行在服务器端的 Java 模板技术，需要依靠 Servlet 容器解析、编译与执行生成纯 HTML 后再回传给浏览器，而现代浏览器自身只具备解析 HTML、CSS 和 JavaScript 的客户端引擎，并不包含 Java 虚拟机与 Servlet 运行时环境。

一、现象直击：双击打开 JSP 文件会发生什么

在日常开发或学习过程中，初学者常常会尝试像打开普通 .html 文件那样，在本地文件资源管理器中直接双击一个 .jsp 文件，或者把文件拖拽到浏览器窗口中。此时，浏览器地址栏显示的通常是类似 file:///Users/username/project/index.jsp 的本地文件路径。

接下来屏幕上展示的绝不是预期的动态网页，而是通常出现以下两种情况之一：

• 情况 A：源码全盘裸露。 浏览器把 .jsp 文件当作普通的纯文本文档（MIME 类型常被判定为 text/plain），页面上直接输出了类似 <% String username = "张三"; %> 的 Java 脚本段落，甚至连 HTML 标签也未经渲染直接显示出来。
• 情况 B：弹出文件下载对话框。 部分浏览器因为无法识别 .jsp 扩展名对应的客户端内容类型，将其当成二进制或未定义数据流，自动弹窗询问用户是否保存该文件到本地。

例如，下面这段原本旨在输出系统当前日期的简单 JSP 代码片段：

<%@ page contentType="text/html;charset=UTF-8" %>
<html>
<head><title>时间页面</title></head>
<body>
  <h1>欢迎访问</h1>
  <p>当前时间是：<%= new java.util.Date() %></p>
</body>
</html>

如果直接双击文件，浏览器输出的并不是格式化好的时间，而是原封不动地将 <%= new java.util.Date() %> 打印在页面上，或者作为无效标签直接隐去。背后的根本原因在于客户端与服务端请求链路的完全不同。

二、核心原因：浏览器与 JSP 运行环境的能力代差

要透彻理解这一问题，必须明确两者的运行环境定位。浏览器本质上是客户端软件，它的职责是接收网络传输过来的静态或脚本资源，并将其渲染成可视化的用户界面。

浏览器的内置引擎架构主要包含两大部分：

1. 排版与渲染引擎（如 Blink、WebKit、Gecko）： 负责解析 HTML 文档构建 DOM 树，解析 CSS 样式表构建渲染树，并完成页面的排版绘制。
2. JavaScript 解释引擎（如 V8、SpiderMonkey）： 负责在客户端单线程沙箱环境中解释执行 ECMAScript 代码，操作 DOM 和 BOM 接口。

注意，在这两套引擎中，没有任何组件认识 Java 语言语法。现代操作系统出于安全与架构解耦考虑，浏览器不仅没有内置 Java 运行时环境（JRE/JVM），而且早在十年前就全面废弃了诸如 NPAPI 这类允许加载外部 Java Applet 插件的底层接口。

当浏览器直接读取包含 <% ... %>、<jsp:include> 或 JSTL 表达式（如 ${user.name}）的 JSP 文件时，HTML 解析器会将其视作未知标签或非法字符。由于解析器无法执行其中的服务端逻辑，这些代码只能被原封不动地输出为字符文本，或者被浏览器的容错机制当成无效 DOM 节点过滤掉。

三、幕后流程：JSP 是如何在服务端被“翻译”成 HTML 的

JSP（JavaServer Pages）的技术本质并不是独立于 Java 的全新语言，它的底层实质就是一个特殊的 Servlet 类。当 Web 容器首次接收到针对某个 JSP 页面的 HTTP 请求时，会经历一整套严格的生命周期转换过程。

以 Apache Tomcat 为例，其内部集成了名为 Jasper 的 JSP 引擎，整个执行链条分为三个核心阶段：

• 第一阶段：翻译阶段（Translation）
  Jasper 引擎读取 index.jsp 文件，将其中的静态 HTML 内容与 Java 脚本代码进行解析。静态文本被转换成类似 out.write("<html>...") 的流输出语句，而 <% ... %> 中的代码则被原封不动提取出来，嵌入到一个继承自 org.apache.jasper.runtime.HttpJspBase（其本身实现了 HttpServlet 接口）的 Java 源码文件中。最终生成一个形如 index_jsp.java 的标准 Servlet 源文件。
• 第二阶段：编译阶段（Compilation）
  Tomcat 内部调用 Java 编译器（如 Eclipse ECJ 或本地 JDK 的 Javac），把上一步生成的 index_jsp.java 编译为平台无关的字节码文件 index_jsp.class，并存放在服务器的工作目录（例如 tomcat/work/Catalina/localhost/...）中。
• 第三阶段：执行与输出阶段（Execution）
  Servlet 容器利用类加载器将该 .class 文件载入 JVM 内存，完成初始化并调用其核心业务方法 _jspService(HttpServletRequest, HttpServletResponse)。在方法执行过程中，动态逻辑与数据库查询依次运行，最终向 HTTP 响应流中写入标准的纯静态 HTML、CSS 与 JS 字符串。

因此，网络传输线路上流动的内容早已没有任何 JSP 语法的痕迹，到达浏览器端的数据就是一份标准的 HTML 文档。浏览器解析这份纯 HTML 时自然能够正常渲染。

四、实践指引：在本地正确运行 JSP 的具体操作步骤

要想正确运行并查看 JSP 页面的渲染效果，必须在本地搭建一个合规的 Servlet 容器。以下以业界最普遍的 Apache Tomcat 配合 JDK 为例，说明从零运行 JSP 的标准操作：

步骤 1：准备 Java 运行时环境（JDK）

JSP 的翻译和编译依赖 JDK 提供的开发工具包。确保本地已安装 JDK 8 或更高版本，并在终端输入命令检查环境：

# 验证 Java 运行环境
java -version

# 验证 Java 编译器
javac -version

若终端能正确打印版本信息（例如 java version "17.0.x"），说明基础环境已就绪。

步骤 2：获取并解压 Servlet 容器（如 Apache Tomcat）

从 Apache Tomcat 官方网站下载对应主版本的二进制压缩包（Binary Distributions，例如 Core 包中的 .zip 或 .tar.gz）。解压到本地不含中文和空格的目录下（例如 /opt/tomcat 或 D:\servers\apache-tomcat-9.0.86）。

步骤 3：放置 JSP 文件到应用目录

进入 Tomcat 的解压目录，定位到 webapps/ 文件夹。你可以在其中新建一个测试工程目录，例如命名为 myapp，然后把编写好的 index.jsp 放入该文件夹中：

apache-tomcat/
  └── webapps/
      └── myapp/
          └── index.jsp   <-- 将编写的 JSP 文件放置于此

步骤 4：启动 Tomcat 服务

打开终端或命令行，进入 apache-tomcat/bin 目录执行启动脚本：

# macOS / Linux 系统执行：
./startup.sh

# Windows 系统执行：
startup.bat

控制台出现 Server startup in [xxx] milliseconds 即代表 Web 容器已启动成功，默认监听在 8080 端口。

步骤 5：通过 HTTP 协议在浏览器中访问

打开浏览器，在地址栏中严禁使用本地路径，必须输入完整的标准 HTTP 地址：

http://localhost:8080/myapp/index.jsp

按下回车后，浏览器向本地 8080 端口发起请求，Tomcat 接收请求并即时完成翻译、编译与运算，最终将脱去所有 JSP 标签的纯净 HTML 内容返回给浏览器，完成正常展示。

五、常见误区与排查清单

在实际操作中，开发者常常会遇到各种与环境配置相关的报错。下表梳理了最常见的几个认知误区与排查方向：

综上所述，JSP 代码之所以不能在浏览器中直接运行，归根结底是因为其服务端的本质属性。浏览器是一个面向纯静态前端标准（HTML/CSS/JS）的呈现客户端，而 JSP 是包含 Java 动态逻辑的服务器端模板。只有通过标准的 HTTP 协议请求部署在 Servlet 容器（如 Tomcat）中的应用，由服务端完成翻译、编译并执行输出为静态 HTML 后，浏览器才能正确解析并呈现完整的网页。