为什么JSP文件中可以写JavaScript？厘清服务端渲染与客户端脚本的关系

作者：青柠

时间：2026-10-30

深入解析为什么JSP文件中可以编写JavaScript代码。从JSP翻译机制、服务端渲染与浏览器执行的时空分离、数据传递模式及常见开发误区展开，厘清Web开发中服务端与客户端的核心关系。

文章目录

JSP文件中之所以能自由编写JavaScript，根本原因在于JSP本质上是一个服务端的模板生成引擎。在Web容器（如Tomcat）的眼中，JSP文件除专门的服务端标签（如 <% ... %> 与 ${ ... }）之外的所有内容——包括HTML标签、CSS样式以及 <script> 标签内的JavaScript代码——都被统一视为毫无特殊语义的“静态模板文本（Template Text）”。容器在解析JSP时，并不理解也绝不执行JavaScript语法，而仅仅是将整段脚本包裹为字符串，通过 out.write() 原样输出到HTTP响应流中；只有当该字符流被网络传输至用户的浏览器后，浏览器内置的JavaScript引擎才会对其进行语法解析与执行。

一、机制剖析：Web容器如何看待JSP中的JavaScript

在很多初学者的直觉中，一个包含 <% String msg = "Hello"; %> 与 <script>console.log(msg);</script> 的文件似乎是在同一处“同时运行”的。这种混淆正是许多语法错误和认知偏差的根源。要彻底理解这一问题，首先必须深入Java Web容器（例如Apache Tomcat的Jasper引擎）对JSP文件的编译处理机制。

JSP文件并不是直接被操作系统或浏览器读取的，它的生命周期必然经历以下几个严格的内部转化阶段：

代码解析与代码转译（Translation）：当用户首次向服务器请求一个JSP页面时，Web容器会将 .jsp 文件逐行翻译为一个标准的Java源文件（即继承自 HttpJspBase 的 Servlet，通常命名为 xxx_jsp.java）。
字节码编译（Compilation）：容器调用Java编译器（如JDT或javac），将生成的 .java 文件编译为可在Java虚拟机（JVM）中运行的 .class 字节码。
类加载与执行（Execution）：容器加载该Servlet类并实例化，每次客户端HTTP请求到达时，均执行其内部的核心服务方法 _jspService(HttpServletRequest, HttpServletResponse)。

在这个转译规则中，JSP规范对内容作出了明确的黑白二分：

凡是写在 <% ... %>、<%! ... %>、<%= ... %> 以及EL表达式 ${ ... } 中的代码，会被提取出来作为Java语句、成员变量或表达式求值代码插入到Servlet的方法体中。
除此之外的所有字符，不论是 <div>、普通的文本汉字，还是完整的 <script>function test() { ... }</script>，在JSP引擎看来没有任何区别。它们都被归为静态模板文本（Template Text）。

我们可以通过一段具体的示例代码来观察这一转译差异。假设我们编写了如下的JSP源码片段：

<%-- JSP 源码片段：sample.jsp --%>
<%@ page contentType="text/html;charset=UTF-8" %>
<%
    String serverTimestamp = new java.util.Date().toString();
%>
<html>
<head>
    <script>
        function initPage() {
            var localNotice = "客户端已加载";
            console.log("服务端生成于: " + "<%= serverTimestamp %>");
            alert(localNotice);
        }
    </script>
</head>
<body onload="initPage()">
    <h1>欢迎访问管理系统</h1>
</body>
</html>

当Tomcat将上述 sample.jsp 翻译为后台的 sample_jsp.java 时，其 _jspService 方法的实质逻辑如下：

// Tomcat 转译后的 Servlet 内部逻辑
public void _jspService(final HttpServletRequest request, final HttpServletResponse response)
    throws java.io.IOException, ServletException {

    JspWriter out = response.getWriter();
    
    // 1. 执行 JSP 中的 Java 逻辑
    String serverTimestamp = new java.util.Date().toString();

    // 2. 将模板文本逐行调用 out.write() 原样写出
    out.write("<html>\r\n<head>\r\n");
    out.write("    <script>\r\n");
    out.write("        function initPage() {\r\n");
    out.write("            var localNotice = \"客户端已加载\";\r\n");
    out.write("            console.log(\"服务端生成于: ");
    out.print(serverTimestamp); // <%= serverTimestamp %> 表达式求值后转为字符串输出
    out.write("\");\r\n");
    out.write("            alert(localNotice);\r\n");
    out.write("        }\r\n");
    out.write("    </script>\r\n</head>\r\n");
    out.write("<body onload=\"initPage()\">\r\n");
    out.write("    <h1>欢迎访问管理系统</h1>\r\n</body>\r\n</html>");
}

由此可见，对Tomcat来说，function initPage() { ... } 和 <h1>欢迎访问管理系统</h1> 在地位上完全相同。它不会检查你的JavaScript函数有没有写错分号，也不会验证 var localNotice 是否符合ES规范。服务器唯一的任务就是将这些预先写好的字符输出到HTTP响应缓冲区。

为什么JSP文件中可以写JavaScript？厘清服务端渲染与客户端脚本的关系 — 图1：JSP转译为Servlet后，JavaScript代码以字符串常量形式输出到响应流的完整全景

二、时空分离：服务端渲染与客户端执行的生命周期

之所以在编写JSP时容易产生困惑，是因为我们在同一个文本编辑器中同时看到了Java代码和JavaScript代码。要建立坚实的开发心智模型，必须将二者在时间维度（执行时机）与空间维度（运行环境）上做彻底的物理剥离。

1. 空间维度的彻底隔离

JSP中的Java逻辑运行在服务器端的JVM内。它拥有操作服务器系统资源的全部权限：可以直接连接MySQL数据库、读写服务器磁盘文件、访问Redis缓存、操作HTTP Session等；但它绝不可能直接触碰用户的物理屏幕、鼠标光标，也不可能直接读写客户端浏览器的 localStorage。

相反，JavaScript代码运行在客户端用户的浏览器进程（如Chrome的V8引擎、Safari的JavaScriptCore）内。它运行在一个严密的沙箱环境中：可以直接操作DOM节点、修改CSS样式、监听键盘与点击事件；但它绝对无法直接读取服务器上的数据库连接池，也无法直接调用服务器端的一个Java Bean方法。

2. 时间维度的先后衔接

这两个环境不仅物理相隔，其生命周期在时间线上更是一前一后、互不重叠：

阶段 A（服务端计算与装配）：当浏览器发起HTTP请求后，JSP在服务器端执行。此时所有的Java代码运行完毕，数据计算完成，页面拼装为完整的HTML字符文本。随后，HTTP响应头与响应体被刷新写出（Flush），JSP本次请求的服务端生命周期彻底结束并被垃圾回收。
阶段 B（网络传输过渡）：生成的HTML与包含其中的JavaScript纯文本穿过互联网光纤或无线信道，传输至用户终端。在这一阶段，代码仅是一串无意识的字节数据。
阶段 C（客户端解析与激活）：浏览器接收到数据包，HTML解析器开始逐行构建DOM树。当解析到 <script> 标签时，浏览器挂起DOM解析，唤醒JavaScript引擎，这才真正开始为JavaScript代码分配堆栈内存、定义变量并执行逻辑。

三、跨界协作：服务端向客户端注水与异步请求通道

既然两个环境完全隔离，为什么日常开发中又能够实现“JSP向JS传递数据”或者“JS将数据提交给JSP后台”呢？这依赖于两种完全不同的数据传递通道。

1. 模式一：服务端向客户端注水（Server-to-Client Injection）

这是最容易引发认知偏差的模式。在JSP页面渲染期间，我们可以利用EL表达式或JSP表达式标签，把服务端的计算结果直接打印成JavaScript代码的一部分。

<%-- 服务端向客户端变量注入数据 --%>
<script>
    // EL 表达式求值后原样替换为纯字符
    const currentUserId = "${user.id}";
    const isVipUser = ${user.vip}; 
</script>

如果后端 user.id 为 "U1024"，user.vip 为 true，那么最终传输到浏览器的HTML源码就是：

<script>
    const currentUserId = "U1024";
    const isVipUser = true; 
</script>

当浏览器V8引擎运行这段脚本时，它看到的只是一个普通的字符串赋值，完全不知道这曾经是由Java从数据库查出来的。

避坑提示：在直接拼接变量时，如果服务端字符串中含有未转义的双引号（"）、换行符或特殊控制字符，会直接破坏生成的JavaScript语法结构，引发 SyntaxError: Unexpected identifier；若数据来自不可信的用户输入，甚至会导致严重的跨站脚本攻击（XSS）。在生产环境中，复杂的对象必须通过服务端JSON库（如Jackson/Fastjson）进行安全序列化后输出。

2. 模式二：客户端向服务端回传（Client-to-Server Communication）

页面展示在用户屏幕上之后，用户点击按钮、输入表单。此时服务端的JSP线程早就销毁多时了，JavaScript根本不可能直接调用Java类。

要想让数据回到服务端，JavaScript必须借助浏览器提供的网络能力，发起一次新的HTTP请求：

现代标准方案：使用原生的 fetch() API 或 axios，将数据序列化为JSON，向服务端的Servlet或Spring Controller发起异步请求（Ajax），并在拿到JSON响应后动态刷新局部DOM。
传统同步方案：通过 document.getElementById("form").submit() 触发表单整页提交，让浏览器向服务器发起全新的GET/POST请求，由后端再次渲染一个全新的JSP页面。

四、典型误区与开发避坑指南

在实际工程开发中，对JSP与JavaScript执行时空的误解会直接导致典型的逻辑Bug。以下三个是最容易出现的经典错误：

误区一：试图在客户端事件处理中执行JSP Java代码

部分刚接触JSP的开发者常写出类似如下的代码：

<%-- 严重典型错误：在 onclick 中嵌入 Java 业务逻辑 --%>
<button onclick="<% orderService.deleteOrder(orderId); %>">
    删除订单
</button>

错误现象：用户根本还没有点击按钮，甚至页面都还没在浏览器里打开，数据库里的订单就已经被意外删除了！

原理解析：因为 <% orderService.deleteOrder(orderId); %> 是写在JSP执行标签里的。当服务器生成这个页面时，这段Java代码就已经在服务端无条件执行了。执行完成后，它没有输出任何字符，导致最终发送到浏览器的HTML变成了：

<button onclick="">删除订单</button>

正确做法：按钮的 onclick 必须调用客户端JavaScript函数，由该函数通过 fetch 或 XMLHttpRequest 发送HTTP请求到后端的控制器来执行删除。

误区二：在JSP脚本块中试图读取JavaScript变量

另一个高频错误是试图在服务端的Java代码中获取前端运行时的值：

<script>
    var screenWidth = window.innerWidth;
</script>
<%
    // 编译致命错误：Cannot find symbol screenWidth
    int width = screenWidth; 
%>

原理解析：在服务器端编译JSP时，screenWidth 只是一个写在 out.write() 字符串里的普通文字，Java编译器在符号表中根本找不到 screenWidth 这个变量，自然会抛出编译失败异常。记住：服务端永远无法获知客户端运行时的内存状态。

误区三：ES6模板字符串与JSP EL表达式的语法冲突

在现代前端代码中，ES6引入了模板字面量语法 `${variable}`。然而在JSP中，${...} 默认会被识别为服务端的Expression Language（EL表达式）。

<script>
    let userName = "Alice";
    // 问题：JSP 容器会试图在服务端 PageContext/Request 中寻找名为 userName 的属性
    // 若找不到，会将 ${userName} 替换为空字符串输出！
    console.log(`当前用户为: ${userName}`);
</script>

解决方案：

使用反斜杠对 $ 进行转义：console.log(`当前用户为: \${userName}`);，告诉JSP引擎不要在服务端求值。
或者在页面顶部禁用整个页面的EL求值（如果不依赖JSP EL）：<%@ page isELIgnored="true" %>。

五、全景归纳与现代Web技术演进

通过剖析JSP与JavaScript的关系，我们可以清晰地建立起Web开发的体系性认知。将两个世界的核心要素系统整理如下表：

核心对比维度	JSP (服务端渲染 / SSR)	JavaScript (客户端脚本)
运行宿主与环境	服务器 JVM（如 Tomcat、Jetty 等 Web 容器）	用户端浏览器引擎（如 Google V8、JavaScriptCore）
执行时机	HTTP 请求处理阶段（页面响应返回前）	页面下载与DOM构建阶段（用户浏览与交互期间）
对彼此代码的认知	视 JS 代码为纯粹的“静态文本字符流”	完全看不到 JSP 源码（仅能看到替换后的最终HTML）
核心操作对象	数据库、Session、服务端缓存、业务 Service	DOM 树、BOM 窗口对象、CSS样式、用户事件
异常排查与日志	服务器控制台日志（如 `catalina.out`）、HTTP 500	浏览器开发者工具 F12 Console 面板、Network 面板

即便在技术栈高度现代化的今天，Web架构经历了从传统的JSP渲染，到前后端分离的单页应用（SPA），再到以Next.js、Nuxt.js为代表的现代同构服务端渲染（Modern SSR）的演进，其底层的物理模型依然未曾改变——服务端负责利用高性能硬件与数据源快速生成初始的HTML内容骨架，客户端引擎负责接管DOM树并赋予其丰富的动态交互生命。彻底厘清JSP与JavaScript的边界，不仅解决了模板开发中的混淆，更是理解整个Web架构体系演进的关键基石。