JSP与JavaScript的执行时机有什么不同？

一、时钟的先后：一个完整HTTP请求中的执行时间线

初学者容易产生困惑，往往是因为在同一个.jsp源文件里，既看到了Java代码（如<% ... %>），又看到了JavaScript脚本（如<script>...</script>），误以为它们是在同一个地方交替执行的。事实上，这两种代码所经历的时序阶段完全不同。

当用户在浏览器输入网址按下回车时，整个Web生命周期会严格遵循不可逆的时间流向前进：

在图1所示的完整生命周期中，有两个绝对分立的阶段：

1. 服务端阶段（JSP的主场）：当Tomcat接收到对index.jsp的请求后，首先会将JSP翻译成一个Java Servlet源文件（index_jsp.java），编译为字节码类文件（.class），然后调用其_jspService()方法。在此期间，所有的Java代码被执行，从数据库获取数据、处理业务判断，并将计算结果拼接进HTML模板，输出为一串由纯字符组成的HTTP响应体。响应体一旦发送完毕，本次JSP的执行生命周期即告终结。

2. 客户端阶段（JavaScript的主场）：网络传输完成后，用户的浏览器接收到这份纯文本数据包。浏览器并不知道也不关心这个HTML究竟是由JSP、PHP、Python还是纯静态文件生成的。当浏览器内核按顺序解析HTML文档并发现<script>标签时，才激活JavaScript引擎开始编译和执行JS代码。在此阶段，JavaScript才能去读取DOM节点、绑定点击事件、以及发起后续的Ajax通信。

二、递进机制：JSP与JavaScript分步执行细节

为了更清晰地对比二者在运行机制上的递进关系，我们可以将从请求到完全呈现的过程划分为四个步骤：

这四个步骤展示了代码状态的彻底蜕变：

步骤一（服务端模板组装）：JSP本质上是一个“视图模板”。在服务端，JSP中的Java指令（如<%= userName %>或JSTL标签）会被实际的业务值替换。例如，如果后端变量userName的值是"张三"，JSP引擎就会把"张三"打印到输出流里。

步骤二（网络协议传输）：离开服务器的数据流中已经没有任何一行JSP标签、Java类引用或服务端的痕迹。网络管道中传输的仅仅是标准的字符序列。

步骤三（客户端解析启动）：浏览器启动HTML解析器，生成DOM树。一旦解析器碰到JavaScript脚本，浏览器便将控制权转交给JavaScript引擎。此时如果页面中有console.log()，它输出在用户的浏览器控制台（F12），而不是服务器的控制台。

步骤四（运行时交互循环）：首屏渲染完成之后，JSP早已经在几百毫秒甚至几秒前消亡，而JavaScript则长驻于当前浏览器标签页的内存空间中，随着用户的点击、滚动和键盘输入，持续驱动事件循环。

三、代码实测：谁先输出日志？

我们可以通过一段具体的示例代码，直观观察两者的执行位置与输出时机的差异。创建一个名为timing_test.jsp的文件：

<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
<%
    // 这是运行在服务器端的 Java 代码
    long serverTimestamp = System.currentTimeMillis();
    System.out.println("[服务端控制台] 1. JSP 开始执行，当前时间戳：" + serverTimestamp);
    String welcomeMsg = "来自服务器的欢迎信息 (编号: " + serverTimestamp + ")";
%>
<!DOCTYPE html>
<html>
<head>
    <meta charset="UTF-8">
    <title>执行时机实测验证</title>
</head>
<body>
    <h1>执行时机实测对比</h1>
    <p>页面内容已生成。</p>

    <script>
        // 这是运行在客户端浏览器的 JavaScript 代码
        console.log("[浏览器控制台] 2. JavaScript 开始执行，客户端时间戳：" + Date.now());
        const messageFromServer = "<%= welcomeMsg %>";
        console.log("[浏览器控制台] 3. 获取到变量值：" + messageFromServer);
    </script>
</body>
</html>

1. 服务端看到的输出

当浏览器访问此页面时，在服务器的控制台终端（例如Tomcat的catalina.out或IDE的Console中），会立刻输出：

[服务端控制台] 1. JSP 开始执行，当前时间戳：1730346000000

2. 浏览器看到的“网页源代码”

在浏览器中右键点击“查看网页源代码”，你会发现原本在.jsp文件中的<% ... %>已经消失得无影无踪，取而代之的是纯粹的静态文本：

<script>
    // 这是运行在客户端浏览器的 JavaScript 代码
    console.log("[浏览器控制台] 2. JavaScript 开始执行，客户端时间戳：" + Date.now());
    const messageFromServer = "来自服务器的欢迎信息 (编号: 1730346000000)";
    console.log("[浏览器控制台] 3. 获取到变量值：" + messageFromServer);
</script>

3. 客户端控制台的输出

按F12打开浏览器开发者工具的Console标签，你会看到：

[浏览器控制台] 2. JavaScript 开始执行，客户端时间戳：1730346000185
[浏览器控制台] 3. 获取到变量值：来自服务器的欢迎信息 (编号: 1730346000000)

从时间戳可以看出，客户端JS打印出日志的时间明显晚于服务端JSP执行的时间（相隔了网络传输和HTML解析耗时）。

四、常见误区剖析：“为什么在JSP里拿不到JS的变量？”

了解执行时机最直接的实战价值，就是能避免很多初学者常犯的“跨时空代码”错误。

典型错误写法：试图在JSP标签中直接引入JS变量

<script>
    var clientScreen = window.innerWidth;
    <%
        // 错误！此处试图在服务端读取浏览器变量
        // 编译阶段就会报错，因为 clientScreen 变量在 Java 环境中根本未定义
        if ("clientScreen" > 800) {
            // ...
        }
    %>
</script>

为什么这段代码无法工作？因为JSP是先锋，JS是后卫。当服务器在执行<% ... %>内的条件判断时，用户的电脑甚至都还没建立完整的TCP握手，浏览器的窗口对象window和变量clientScreen根本还没诞生。在服务器上寻找一个未来才会在用户电脑上生成的变量，必然引发编译或运行时错误。

五、核心维度对照与总结

为了全面掌握二者的本质差异，我们可以通过下方的矩阵图和对比表进行快速对照：

总结

理解JSP与JavaScript的执行时机，本质上是理解经典Web架构中“服务端渲染”与“客户端运行时”的分工界限。

记住一个最简明的心智模型：JSP是在服务端“写”HTML代码的作者，而JavaScript是留在浏览器里“读”且“操作”HTML代码的管家。作者写完书稿交由邮递员（HTTP）寄出后便已离场，管家在收到书稿之后才根据书稿中的指示开始工作。两者各司其职，不在同一个时间点，更不在同一个空间中运行。