为什么JSP页面中可以编写JavaScript代码？

很多刚接触 Java Web 开发的初学者常常产生困惑：JSP（Java Server Pages）明明是一种在服务端运行的技术，编写的是 Java 代码，为什么页面里却可以随意写 <script> 标签和 JavaScript 代码？其实，根本原因在于 JSP 本质上是一个运行在服务端的“文本模板引擎”。在 Web 容器（如 Tomcat）眼中，JSP 页面中除了特定标签与 Java 脚本片段之外的所有内容——包括 HTML、CSS 以及 JavaScript，都被一律视作普通的“静态文本”。服务端只负责执行 Java 逻辑，并将这些静态文本连同动态运算结果拼接成普通的 HTTP 响应流输出给客户端；而浏览器接收到这串文本后，才会识别并启动内置的 JavaScript 引擎去解析执行脚本。换言之，JSP 允许写 JavaScript，并不是服务器在运行 JS，而是服务器将 JS 脚本作为纯文本原样递交给了浏览器。

图 1：JSP 与 JavaScript 的执行空间与职责分工体系

一、深入核心：JSP编译成Servlet后的真实面貌

为了直观理解这一点，我们可以观察一个 JSP 文件在服务器端被加载时实际发生的事情。当用户首次访问某个 index.jsp 时，Servlet 容器（以 Apache Tomcat 为例）会经历一次“翻译（Translation）”阶段，将 .jsp 文件自动生成为一个标准的 Java 类（即继承自 HttpJspBase 的 Servlet 类，通常命名为 index_jsp.java）。

假设我们在 index.jsp 中写了这样一段包含 JavaScript 的代码：

<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<html>
<head>
    <title>示例页面</title>
    <script type="text/javascript">
        function showWelcome() {
            var msg = "欢迎访问本站！";
            alert(msg);
        }
    </script>
</head>
<body onload="showWelcome()">
    <h1>当前系统时间：<%= new java.util.Date() %></h1>
</body>
</html>

当 Tomcat 将其翻译成 Java Servlet 源代码后，查看其底层的 _jspService() 方法实现，我们会看到非常惊人且直接的逻辑：

public void _jspService(final HttpServletRequest request, final HttpServletResponse response)
    throws java.io.IOException, ServletException {

    JspWriter out = response.getWriter();

    // 所有的 HTML 和 JavaScript 被一字不改地以字符串形式写入输出流
    out.write("<html>\r\n<head>\r\n");
    out.write("    <title>示例页面</title>\r\n");
    out.write("    <script type=\"text/javascript\">\r\n");
    out.write("        function showWelcome() {\r\n");
    out.write("            var msg = \"欢迎访问本站！\";\r\n");
    out.write("            alert(msg);\r\n");
    out.write("        }\r\n");
    out.write("    </script>\r\n");
    out.write("</head>\r\n");
    out.write("<body onload=\"showWelcome()\">\r\n");
    out.write("    <h1>当前系统时间：");
    out.print( new java.util.Date() ); // 动态 Java 表达式在服务端求值
    out.write("</h1>\r\n</body>\r\n</html>");
}

从上面的底层代码可以清清楚楚地看到：对于服务端 Java 虚拟机来说，它压根不知道也不关心什么是 function、什么是 var 或 alert。在 JVM 眼里，这段 JavaScript 代码与普通的 <h1>、<div> 没有任何区别，全都是通过 out.write(...) 倾倒向网络套接字的原始文本字符。

二、四阶段流水线：从编写代码到浏览器执行

从代码敲入编辑器，到最终屏幕上弹出提示框，整个流程经历了一个完整的四阶段接力：

图 2：JSP 中 JavaScript 从源文件编写到终端执行的四阶段流水线

1. 编写阶段（设计态）：程序员在 .jsp 文件中将后端 Java 表达式、JSTL 标签与前端 HTML/CSS/JS 混合排版。
2. 编译阶段（服务端运行）：Web 容器将整个 JSP 转换为一个 Servlet 类。Java 逻辑被编译为字节码指令，而非 Java 标记被统一包装进 out.write(...) 文本输出语句。
3. 传输阶段（网络通信）：客户端发起 HTTP 请求，Servlet 的 _jspService() 执行完毕，生成一段类型为 text/html 的完整文本流，通过网络返回给浏览器。
4. 执行阶段（浏览器运行）：浏览器拿到 HTML 响应并从上到下解析，遇到 <script> 标签时，调用浏览器的 JS 引擎（如 Chrome 的 V8）完成词法分析与代码运行。

三、容易混淆的认知：JSP 与 JavaScript 的本质差异

很多初学者容易将二者混为一谈，产生类似“在 JS 函数中调用 JSP 的 Java 方法”或者“在 JSP 标签里实时读取 JS 变量”的不切实际想法。为了彻底厘清两者的边界，我们可以从以下几个关键维度进行对比：

图 3：JSP 与 JavaScript 在运行环境、时机与通信机制上的核心对比

为什么不能在 JavaScript 里直接获取 JSP 的实时动态值？

很多开发者初学时会写出类似这样的代码：

// 这是一个经典误区：试图在用户点击按钮时让 JSP 重新查库
function refreshData() {
    // 错误理解：以为此时还会去执行服务端的 dao.query()
    var result = "<%= dao.queryLatest() %>";
    console.log(result);
}

这段代码虽然语法看似合法，但其执行机制完全被误解了：<%= dao.queryLatest() %> 在页面刚从服务器生成那一瞬间就已经运行完毕，并将查询结果以固定字符串的形式“硬编码”写死了。无论用户在浏览器里点击多少次按钮，调用 refreshData() 打印出来的永远是页面初次加载时的陈旧字符串，根本不会再次触发服务器的 Java 代码。如果希望在用户操作时重新向服务器获取数据，必须使用 AJAX（异步请求） 或者 Fetch API 重新向后端发起 HTTP 通信。

四、在JSP中混合使用JavaScript的实战规范与避坑指南

在实际项目维护或学习中，在 JSP 页面中嵌入 JavaScript 代码非常普遍。掌握以下规范可以有效避免常见的语法破损与安全隐患：

图 4：JSP 混写 JavaScript 的最佳实践与架构解耦规范

1. 将后端变量注入前端时必须注意引号闭合

如果需要把 Java 后端的字符串输出给 JS 变量，必须在输出标签外层加上单引号或双引号：

<%
    String userName = (String) request.getAttribute("userName");
    if (userName == null) userName = "访客";
%>
<script>
    // 正确：用单引号包裹输出内容，保证浏览器解析为字符串字面量
    var currentUserName = '<%= userName %>';
    console.log("当前登录人：" + currentUserName);
</script>

若漏掉了单引号写成 var currentUserName = <%= userName %>;，当 userName 的值为 "zhangsan" 时，浏览器收到的代码就是 var currentUserName = zhangsan;，此时 JS 引擎会误认为 zhangsan 是一个未声明的变量名，直接抛出 Uncaught ReferenceError: zhangsan is not defined 错误。

2. 防御 XSS 跨站脚本注入风险

推荐使用 JSTL 的 <c:out> 标签进行字符转义，或者使用标准的 JSON 序列化工具将整个复杂对象转为合法的 JSON 字符串后再注入前端：

<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
<script>
    // 使用 JSTL 避免特殊字符直接破坏 JS 语法结构
    var safeKeyword = '<c:out value="${param.keyword}" escapeXml="true"/>';
</script>

3. 现代工程推荐：通过 HTML5 data-* 属性进行解耦

为了让 JavaScript 代码更加模块化，避免在 .js 文件中出现后端的 JSP 语法标签，目前行业更倡导将 Java 数据通过 HTML5 的自定义属性挂载在 DOM 节点上：

<!-- JSP 中仅负责在 DOM 上渲染属性 -->
<div id="userCard" data-userid="${user.id}" data-role="${user.role}"></div>

<!-- 独立的 app.js 文件中直接读取，实现前后端语法彻底分离 -->
<script src="/static/js/app.js"></script>

在外部脚本中只需使用原生语法读取：

const userCard = document.getElementById('userCard');
const userId = userCard.dataset.userid;
const role = userCard.dataset.role;

五、总结

“为什么 JSP 页面中可以编写 JavaScript 代码？”的核心答案非常质朴：JSP 是一种文本生成技术，它不会解析也不会限制你写什么前端脚本。浏览器才是 JavaScript 真正的主场，而 JSP 只是一个在服务端帮助我们将 HTML、CSS 与 JavaScript 打包运送给浏览器的“搬运工”与“组装者”。

理解了服务端渲染（SSR）与客户端脚本执行的时空分离，就能在日常 Web 开发中游刃有余地处理数据传递、清晰划分前后端职责，从容应对从传统 JSP 维护到现代前后端分离架构的技术演进。