技术演进中的开发沉思-178 JSP :前世今生（下）

在 JSP 统治 Java Web 开发的黄金年代，我们这批老程序员就认为它会不会一直 “常青”。因为我一直认为，随着业务复杂度提升、用户体验要求升级，JSP 自身的硬伤逐渐暴露，新的技术肯定会替代他。现在回过头看看，它的衰落不是偶然，而是技术演进的必然结果。

一、盛极而衰 

1. 缺陷

JSP 的成功源于它解决了纯 Servlet 的痛点，但它的设计基因里，藏着几个无法克服的缺陷。当年我们团队维护一个百万级用户的电商平台，这些缺陷被无限放大，最后成了压垮骆驼的 “最后一根稻草”。

强耦合与弱复用性

JSP 从诞生起就和 Servlet API、Java EE 容器深度绑定 —— 它依赖request、response等对象，必须运行在 Tomcat、WebLogic 等服务器上，无法像普通 HTML 文件那样独立打开，更没法脱离容器进行单元测试。

当年我们想复用一个 “商品卡片” 的 JSP 片段到另一个项目，不仅要复制 JSP 文件，还得把依赖的 JavaBean、Servlet 配置一起搬过去，稍不注意就因为 “找不到 request 对象” 报错。更头疼的是测试：想验证一个 JSP 页面的渲染效果，必须启动整个应用服务器，再模拟请求，比测试纯前端页面麻烦 10 倍。对比现在的 Vue 组件，复制粘贴就能用，还能单独在浏览器预览，当年的 JSP 简直像个 “绑着手脚的巨人”。

视图能力单一

JSP 的核心定位是 “服务端渲染 HTML”，可随着 Ajax 技术兴起，用户开始追求 “无刷新交互” 的流畅体验，JSP 就显得力不从心了。

当年我们做电商的 “购物车实时更新” 功能，用 JSP 实现的话，要么刷新整个页面，要么在 JSP 里嵌一堆 JavaScript 代码，通过<%= %>输出后端数据到脚本里，代码混乱到不忍直视。有次为了实现 “商品数量修改后实时算总价”，我们在 JSP 里写了 200 多行混合 Java 和 JS 的代码，后期改需求时，改一行代码就要同时兼顾后端逻辑和前端交互，差点把新人逼走。而用 Ajax 调用纯 API 接口，前端单独处理逻辑，就清爽多了 —— 可 JSP 的设计初衷，根本没考虑过这种 “服务端只给数据、前端负责渲染” 的场景。

调试困难

JSP 本质是 Servlet，可它的调试体验却比 Servlet 差太多。当年排查一个 JSP 页面的空指针异常，浏览器只提示 “500 错误”，日志里只显示 “_jspService 方法第 123 行报错”，可对应的 JSP 文件里根本没有行号对应 —— 因为 Tomcat 编译 JSP 时，会自动添加大量容器代码，实际报错的行号和我们写的 JSP 行号对不上。

有次一个 “商品价格显示错乱” 的 bug，我们查了半天，最后发现是 JSP 里的<%= product.getPrice() %>被编译后，和容器生成的 HTML 转义代码冲突了，导致价格数值被截断。这种 “看得见的代码没问题，看不见的编译代码出问题” 的情况，在 JSP 开发中太常见了，每次排查都要熬好几个通宵。

2. 来自后端模板引擎的挑战

JSP 的缺陷让开发者们开始寻找更好的 View 层方案，于是一批后端模板引擎应运而生，它们保留了 “服务端渲染” 的核心需求，却解决了 JSP 的诸多痛点，成了 JSP 的 “替代者”。

专注 View 层

这些模板引擎的核心思路是 “剥离容器依赖，专注模板渲染”—— 它们不再依赖 Servlet API，能独立解析模板、渲染数据，既可以在服务端使用，也能嵌入其他非 Web 项目，灵活性远超 JSP。当年我们团队从 JSP 迁移到 Freemarker 后，测试效率提升了不少：不用启动服务器，写个简单的 Javamain 方法就能验证模板渲染效果。

代表性技术：Freemarker 与 Thymeleaf 的 “逆袭”

• Freemarker：当年最火的模板引擎之一，语法比 JSP 简洁，不依赖任何容器，性能也更优。比如循环渲染商品列表，Freemarker 的语法比 JSTL 更直观：

  <#list products as p>
  <tr><td>${p.id}</td><td>${p.name}</td><td>${p.price?string("0.00")}</td> <!-- 内置格式化功能，JSP需要自定义标签 -->
  </tr>
  </#list>
  

  当年我们用 Freemarker 重构了电商的商品详情页，模板文件体积减少了 30%，渲染速度也快了不少 —— 因为 Freemarker 不用像 JSP 那样经过容器编译成 Servlet，直接解析模板就能生成 HTML。

• Thymeleaf：后来居上的 “Spring 官方推荐” 模板引擎，最大的优势是 “自然模板”—— 它的模板文件是标准的 HTML 文件，不带任何特殊标签，美工可以直接用浏览器打开预览，开发者再在上面添加模板语法。比如：

  <tr th:each="p : ${products}"><td th:text="${p.id}">1</td> <!-- 静态预览时显示“1”，服务端渲染时替换为真实ID --><td th:text="${p.name}">商品名称</td>
  </tr>
  

  这种 “原型即页面” 的特性，彻底解决了 JSP 时代 “美工改图难” 的问题。当年我们做政务系统，美工直接用 Thymeleaf 模板做设计图，我们再添加动态语法，前后端协作效率提升了一倍。

这些模板引擎的优势很明显：更好的性能、更清晰的语法、更强的功能（如片段缓存、内置格式化），最重要的是真正实现了 View 层与容器的解耦。它们的出现，让 JSP 在 “服务端渲染” 这个领域也失去了竞争力。

3. 前后端分离的降维打击

如果说模板引擎是 “同门竞争”，那前后端分离架构的兴起，就是对 JSP 的 “降维打击”—— 它彻底颠覆了 JSP 赖以生存的 “服务端渲染” 模式，让 JSP 逐渐被边缘化。

架构革命：前后端 “分家”，各司其职

前后端分离架构的核心是 “后端只提供 API，前端独立开发”：

• 后端（API Server）：不再负责页面渲染，只专注于业务逻辑，提供 RESTful API，返回 JSON/XML 数据。技术栈可以是 Spring Boot、Spring MVC 等，不用再关心前端如何展示数据。
• 前端（Client）：作为独立的 SPA（单页应用），负责数据渲染和用户交互。技术栈可以是 React、Vue、Angular 等，拥有自己的路由、状态管理、组件系统。
• 连接方式：通过 Ajax 或 HTTP 请求调用后端 API，实现数据交互。

当年我们第一次用前后端分离重构电商的用户中心，后端团队专注写 API，前端团队专注做交互，并行开发，上线时间比预期提前了半个月。更惊喜的是，用户体验大幅提升：切换页面不用刷新，表单提交实时验证，加载速度也快了很多 —— 这些都是 JSP 架构难以实现的。

前后端分离的绝对优势：JSP 望尘莫及

对比 JSP 架构，前后端分离的优势可以用 “全方位碾压” 来形容：

• 职责绝对分离：后端写 API，前端做页面，再也不用像 JSP 时代那样 “后端写 HTML，前端改 Java 代码”。当年我们团队后端和前端彻底分开，后端专注性能和业务逻辑，前端专注用户体验，冲突减少了 80%。
• 用户体验飞跃：SPA 应用支持局部刷新、无刷新跳转，媲美原生应用的流畅度。比如 JSP 时代修改用户信息，提交后要刷新整个页面；前后端分离后，只需要调用 API 更新数据，页面局部刷新，用户体验天差地别。
• 强大的前端生态：现代前端框架提供了组件化、状态管理、路由、打包构建等一整套工程化解决方案。比如 Vue 的组件可以复用在多个项目，React 的状态管理能轻松处理复杂交互，这些都是 JSP 的 “标签复用” 无法比拟的。
• 多端复用：一套后端 API 可以同时服务于 Web、iOS、Android 等多个客户端。当年我们的电商 API，不仅供 Web 端使用，还对接了 APP 和小程序，不用像 JSP 时代那样为不同客户端单独开发页面。

前后端分离架构的出现，彻底淘汰了 JSP 的核心应用场景。从那以后，新项目几乎没人再选 JSP，就连老项目也在逐步迁移到前后端分离模式 ——JSP 的衰落，已成定局。

二、彻底遗忘

如今再聊 JSP，它已不再是技术选型的 “主角”，但它在 Java Web 发展史上留下的印记，依然值得我们深思。作为见证过它兴衰的老程序员，我想聊聊它的现状和带给我们的启示。

1. JSP 的现状

教学入门：Java Web 的 “启蒙老师”

JSP 依然是许多高校和培训机构的 Java Web 入门技术。因为它直观地展示了 “请求 - 响应” 的完整流程：浏览器发送请求，服务端处理后渲染 JSP 页面，再返回给浏览器。对于初学者来说，这种 “所见即所得” 的模式更容易理解 Web 开发的核心逻辑。当年我就是通过 JSP 入门 Java Web 的，后来学习 Spring MVC、前后端分离时，也因为有了 JSP 的基础，更容易理解 MVC 思想和前后端交互的原理。

新技术中被抛弃

在基于 Spring Boot 的新项目中，官方已明确不推荐使用 JSP。因为 Spring Boot 默认支持的模板引擎是 Thymeleaf，且 JSP 在嵌入式容器中存在诸多兼容性问题。现在的新项目，要么用 Thymeleaf 等模板引擎做服务端渲染，要么直接采用前后端分离架构 ——JSP 已彻底退出了新项目的技术选型清单。

2.  JSP 的演进启示

架构思想的演进

JSP 的演进史，本质是 Web 架构 “解耦” 的历史：从纯 Servlet 的 “Java 代码混 HTML”，到 JSP+Servlet+JavaBean 的 MVC 架构（业务与视图分离），再到前后端分离（前后端彻底解耦）。每一次演进，都是为了解决 “职责混乱、协作困难” 的痛点。这告诉我们：好的架构一定是 “职责清晰、低耦合高内聚” 的，随着业务和技术的发展，架构也必须不断迭代，才能适应新的需求。

技术选型的生命力

JSP 的成功，是因为它解决了纯 Servlet 开发效率低、维护难的痛点；它的衰落，是因为它无法满足富客户端交互、前后端高效协作的新痛点。这说明：技术的生命力不在于它有多 “先进”，而在于它能否解决当前的核心痛点。当年我们选择 JSP，是因为它能让我们快速开发动态网页；后来放弃 JSP，是因为前后端分离能让我们提升用户体验和团队效率。技术选型没有 “一劳永逸”，只有 “适者生存”。

重新定义 View 层

JSP 时代的 View 层，只是一个 “生成 HTML 的页面”，依赖服务端的逻辑；而现在的 View 层，可能是一个拥有自己路由、状态管理、业务逻辑的独立 SPA 应用。这让我们明白：随着技术的发展，View 层的边界在不断扩展，它不再是后端的 “附属品”，而是可以独立演进、独立部署的 “核心组件”。这种认知的转变，也推动了前端工程化、微前端等新技术的发展。

最后小结

JSP 是特定历史时期的杰出产物，它就像一位战功赫赫的 “老将军”，在 Java Web 的 “青春时代” 立下了汗马功劳。它成功地解决了从纯 Servlet 到页面导向开发的过渡问题，催生了经典的 MVC 架构思想，培养了一代 Java Web 开发者。虽然现在它已不再是新项目的主角，但它的兴衰史，浓缩了 Web 开发架构的演进逻辑。理解 JSP 的优点和缺陷，能让我们更清晰地把握现代 Web 开发的精髓 —— 无论是服务端渲染还是前后端分离，核心都是为了 “更高效地开发、更优质地体验、更灵活地扩展”。未完待续.............