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

打开一个典型的 Java Web 项目，在 .jsp 文件中往往能看到这样一幕：最上面是 <%@ page ... %> 指令，中间穿插着服务端的 Java 代码片段 <% ... %>，而在 HTML 结构的下方，又整整齐齐地写着 <script> 标签和原生的 JavaScript 脚本。初次接触这种写法的开发者常常会产生疑惑：JSP 明明是由 Web 服务器解析的 Java 技术，而 JavaScript 是在客户端浏览器运行的脚本，两者运行环境与执行宿主截然不同，为什么可以直接写在同一个文件里？

核心原因非常纯粹：对 JSP 容器而言，除了专有的 JSP 标签和表达式外，文件中的 HTML 标签、CSS 样式以及 JavaScript 代码，本质上都只是“静态模板文本”。 JSP 引擎在执行时根本不理解也不执行任何 JavaScript 语法，它仅仅是将这些脚本字符原封不动地写入 HTTP 响应数据流，发送给客户端浏览器；最终由浏览器的 JavaScript 引擎去解析和执行这部分代码。

一、运行环境与执行阶段：服务端与客户端的时空隔离

要透彻理解这个问题，首先必须分清 JSP 与 JavaScript 各自在 Web 请求周期中扮演的角色以及所在的执行宿主。

当客户端浏览器在地址栏输入一个 JSP 地址并发起请求时，整个过程经历了两个截然不同、前后相继的阶段：

1. 服务端阶段（JSP 容器）： Web 容器（如 Tomcat）接收到 HTTP 请求后，找到对应的 .jsp 文件。如果该文件是首次访问或发生过修改，容器会先将其翻译为一个 Java Servlet 类（.java），编译为字节码（.class），随后加载并在 JVM 中执行。执行完毕后，服务端向客户端输出标准的 HTTP 响应文本。
2. 客户端阶段（用户浏览器）： 浏览器通过网络接收到该 HTTP 响应报文。此时浏览器并不知道这个页面来自 JSP、PHP 还是普通的静态 HTML 文件，它只负责按照 Web 标准自上而下解析文本流。当遇到 <script> 标签时，浏览器内置的 JavaScript 引擎（如 V8、SpiderMonkey）被激活，开始执行内部的 JavaScript 逻辑。

二、转译机制：JSP 容器眼中的“普通文本”

为了直观看到 JSP 容器如何对待 JavaScript，我们可以观察一个 JSP 文件在 Tomcat 中转译后的实际 Java 代码。

假设编写了一个简单的 demo.jsp，内容如下：

<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<html>
<head>
    <title>测试页面</title>
</head>
<body>
    <%
        String username = "张三";
    %>
    <h1>欢迎进入系统</h1>
    <script>
        let currentUser = "<%= username %>";
        console.log("当前登录人: " + currentUser);
        alert("欢迎你，" + currentUser);
    </script>
</body>
</html>

当容器解析此文件时，会把该页面转译成一个继承自 HttpJspBase 的类（例如 demo_jsp.java），核心处理逻辑位于其 _jspService 方法中：

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

    JspWriter out = response.getWriter();
    // 1. 普通 HTML 文本直接输出
    out.write("<html>\r\n<head>\r\n    <title>测试页面</title>\r\n</head>\r\n<body>\r\n");

    // 2. JSP 脚本片段中的 Java 代码原样保留为业务逻辑
    String username = "张三";

    out.write("    <h1>欢迎进入系统</h1>\r\n");

    // 3. JavaScript 代码全都被放入了 out.write() 中当作纯字符串发送！
    out.write("    <script>\r\n");
    out.write("        let currentUser = \"");
    out.print( username ); // 表达式被计算并拼装入文本
    out.write("\";\r\n");
    out.write("        console.log(\"当前登录人: \" + currentUser);\r\n");
    out.write("        alert(\"欢迎你，\" + currentUser);\r\n");
    out.write("    </script>\r\n</body>\r\n</html>");
}

从底层转译生成的代码中可以看出：

• 对于容器来说，<script>、let currentUser = ...、console.log(...) 与普通文本 <h1> 没有任何地位上的差异。
• 容器不需要安装 JavaScript 解释器，也不需要理解 JavaScript 是否语法正确；它只履行自己的职责——拼装字符流并写回客户端。
• 这也解释了为什么即便你在 JSP 中的 JavaScript 代码里写了一个拼写错误（例如将 console.log 写成 console.lug），JSP 在服务器编译和运行时绝对不会报错，只有当浏览器解析到这一行时才会抛出客户端异常。

三、动态协同：服务端数据向客户端脚本的单向传递

虽然 JSP 和 JavaScript 在两个独立的时空中运行，但在早期的 Web 架构中，两者结合之所以强大，是因为 JSP 具备将服务端的动态数据“烙印”在前端脚本中的能力。

1. 服务端数据注入 JS 变量

通过 JSP 表达式 <%= expression %> 或 EL 表达式 ${expression}，可以将服务器内存中的对象、属性直接打印成 JavaScript 变量初值：

<script>
    // 数值类型直接输出
    const currentUserId = ${sessionScope.user.id};

    // 字符串类型需由 JS 侧的引号包裹
    const currentUserName = "${sessionScope.user.name}";

    // 布尔类型
    const isAdmin = ${sessionScope.user.role == 'ADMIN'};
</script>

在服务器将这段内容输出给浏览器之前，${sessionScope.user.name} 就已经被替换成了真实姓名（例如 "李四"）。当浏览器拿到代码时，看到的已经是一段标准、静态的 JavaScript 赋值语句 const currentUserName = "李四";。

2. 核心边界限制：时序不可逆

很多初学者会犯一个典型错误：尝试在 JSP 页面内部，直接用 Java 代码读取 JavaScript 中定义的变量，例如：

<script>
    var clientScreen = window.innerWidth;
</script>
<%
    // 错误观念：试图在此处获取 clientScreen！
    // 此时服务端早就执行完了，页面还没到浏览器，根本不存在客户端屏幕宽度数据。
%>

记住核心时序法则：服务端先运行并结束，客户端后开始。数据只能随 HTTP 响应从服务端流向客户端；如果 JavaScript 想要把数据回传给服务端，必须重新发起 HTTP 请求（如通过 AJAX、Fetch 或 Form 表单提交）。

四、开发混写时的易错点与注意事项

虽然在 JSP 中编写 JavaScript 非常自由，但也因为这种“代码混排”特性，在日常开发中极易引发若干隐蔽缺陷：

1. ES6 模板字符串语法冲突

在现代前端开发中，常常使用 ES6 的反引号语法进行字符串插值：`Hello, ${name}!`。但在 JSP 2.0 及更高规范中，${...} 默认会被识别为 JSP 表达式语言（EL 表达式）。

• 如果直接在 JSP 的 <script> 中书写 let str = `User: ${user.name}`;，JSP 引擎会在服务端尝试寻找名为 user 的 page/request/session 属性。如果服务端没有这个属性，该表达式就会被求值为空白，导致输出到浏览器的代码变成 let str = `User: `;。
• 解决方法：
  • 使用反斜杠对 $ 进行转义：let str = `User: \${user.name}`;，这样 JSP 容器就会将其当作纯文本原样输出给客户端。
  • 或者在页面顶端指令中临时关闭当前页面的 EL 解析：<%@ page isELIgnored="true" %>（通常不推荐全局关闭）。

2. 字符拼接引发的 XSS 安全漏洞

当通过 <%= request.getParameter("keyword") %> 类似的方式将外部用户输入直接渲染到 JavaScript 变量时，极易造成反射型 XSS（跨站脚本攻击）：

<script>
    // 危险写法！如果输入中包含双引号及恶意代码："; alert('XSS'); //
    var searchKeyword = "<%= request.getParameter("keyword") %>";
</script>

防范措施： 服务端在向 JavaScript 上下文输出字符串时，必须进行针对 JavaScript 上下文的转义（如使用 Apache Commons Text 的 StringEscapeUtils.escapeEcmaScript()），或先序列化为标准 JSON 字符串。

3. 代码格式与职责耦合严重

在 JSP 页面内大量内嵌复杂的 JavaScript 业务逻辑会导致代码可读性急剧下降。现代工程实践通常建议：将通用的 JavaScript 代码抽取到独立的 .js 外部静态文件中，JSP 仅保留必要的 <script src="main.js"></script> 引用；对于必要的初始配置数据，可以通过 HTML5 的 data-* 属性挂载在 DOM 节点上，或集中挂载在一个全局配置对象中。

五、知识回顾与概念对照

为了进一步巩固理解，以下汇总了 JSP 与 JavaScript 在实际运行中的核心差异对照：

对比维度	JSP (JavaServer Pages)	JavaScript (页面脚本)
执行宿主	服务端 Web 容器（如 Tomcat、Jetty 等 JVM 进程）	客户端终端浏览器（如 Chrome、Safari 等 JS 引擎）
执行时机	用户发起 HTTP 请求处理期（先执行）	HTML 文本下载完毕被浏览器解析时（后执行）
对彼此的感知	将 JS 视作普通的输出文本字符流，不解析其逻辑	只看到被 JSP 渲染完成后的最终 HTML/JS，不知道 JSP 存在
语法报错表现	JSP 语法错误导致 500 服务器转译/编译失败	浏览器开发者工具 Console 抛出未捕获脚本异常
数据通信渠道	通过 <%= %>、EL 单向输出到页面	通过 AJAX、Fetch 或 Form 向服务端路由发起新请求