JSP的兴衰与遗留系统维护：从巅峰到渐进式改造指南

说实话，现在再聊 JSP，总有种翻旧相册的感觉。JSP 这个名字，在 Java 后端开发里曾经是响当当的招牌，几乎所有 Java Web 教程都会教你用它做动态页面，那时候要说 “Java 做网站”，第一反应就是 JSP。可今天，新项目里已经很少看到 JSP 的影子了，甚至不少年轻开发者只听过名字、没见过真实代码。这篇文章不是给 JSP 唱挽歌，而是想认真聊聊它从巅峰滑落的原因，是谁替代了它，以及现在还在维护 JSP 老项目的人，该怎么跟这个“老伙计”相处。如果你是要做技术选型的新手、正在维护遗留系统的开发，或者单纯对技术演进感兴趣，这篇都值得看完。

1. JSP 当年为什么能火起来

1.1 那个时代的正确答案：服务端渲染就是主流

往回看十几年，Web 应用的主流形态跟今天完全是两码事。那时候没有前后端分离，没有 SPA，手机 App 也还没爆发，绝大多数 Web 系统都是服务端渲染的：前端页面由服务器动态生成，用户每次点击，浏览器都会向服务器发起请求，服务器把处理完的结果渲染成完整 HTML 再返回。

JSP 的全称是 JavaServer Pages，说白了就是允许开发者在 HTML 里嵌入 Java 代码，让页面能够根据请求参数、数据库数据、用户状态动态生成内容。它的底层原理并不神秘：JSP 文件会被容器（比如 Tomcat）先翻译成一个 Servlet 的 Java 源文件，再编译成 Class 执行。也就是说，JSP 其实是一种“Servlet 的模板化封装”，它把 Servlet 里输出 HTML 的繁琐过程简化成了页面写法。

在那个年代，JSP 几乎是 Java 企业级开发的标准答案。想当年做 OA 系统、ERP、政府门户，Java 后端搭配 JSP 页面是标配组合。我印象最深的是 2008 年前后，公司接一个业务管理系统，前端页面清一色 JSP，后台 JavaBean + Servlet，数据库用 Oracle，整套东西跑得很稳。那会儿我身边的同事很少质疑 JSP 的能力，因为确实没什么更好的选择。

1.2 核心武器：在 HTML 里直接写 Java

JSP 当年的核心竞争力，就是“门槛低、见效快”。只要你会 HTML，再掌握几个 JSP 标签，就能把页面跟后端数据打通。最典型的写法是脚本片段和表达式：

<% List<User> users = (List<User>) request.getAttribute("users"); for (User u : users) { %> <tr> <td><%= u.getName() %></td> <td><%= u.getEmail() %></td> </tr> <% } %>

这段代码放在今天看非常粗糙，但在当时，这就是日常工作流。从数据库中查出用户列表，塞到 request 里，页面循环渲染，搞定。结合 JSTL 标签库和 EL 表达式，还可以进一步去掉大部分脚本片段：

<c:forEach var="u" items="${users}"> <tr> <td>${u.name}</td> <td>${u.email}</td> </tr> </c:forEach>

现在网上有个热词叫“jsp个人信息展示页面”，这个需求放在 JSP 时代，就是上面这个套路。做一个用户中心，顶部显示用户名，中间是个人的基本资料表格，下面可能挂着最近操作记录的列表，后端 Servlet 查询数据，Forward 到 JSP 页面渲染。一个人包揽前后端，大半天就能交付，效率和效果在当时都说得过去。

1.3 Java 生态光环：为什么企业大项目认它

JSP 能火，不光是本身好用，更重要的是它背后站着 Java。那个年代企业级应用采购，技术栈里只要有 Java，潜意识里就觉着“正规、稳定、可扩展”。Java 有跨平台能力，有成熟的类库，有大规模并发处理的经验，这些都给 JSP 加分。

相比之下，同时代的 ASP 虽然在微软生态里很流行，但平台绑定太紧；PHP 上手容易、部署方便，但很多大型企业项目对 PHP 的工程化管理、性能调优路径心存疑虑。JSP 的定位正好卡在中间：既能写小项目，也能撑起大系统，而且围绕它有一整套 Servlet、JavaBean、JDBC、XML 配置的完整技术体系。所以无论是银行、电信、政府还是传统企业，Java Web 的标配里几乎都会出现 JSP。

2. 时代变了：JSP 是怎么被一步步抛下的

2.1 页面与逻辑耦合，成了维护的定时炸弹

JSP 快速上手是优点，但也埋下了大坑：它允许把 Java 代码直接塞进 HTML，时间一长，页面里的业务逻辑就越堆越多。一个 JSP 文件里能同时出现数据库连接、权限判断、数据格式化、HTML 标签、JavaScript 拼接，五颜六色的<% %>混杂在标签中间。

这种代码在项目初期跑得飞快，但半年之后再看，谁都头疼。改样式可能要顺带解一个 if-else，改业务逻辑又得从几百行 HTML 里把 Java 代码捞出来。更难受的是，JSP 页面没法做单元测试，逻辑正确与否只能靠启动 Tomcat 用浏览器验证。项目规模一大，JSP 文件数量动辄上百，模块之间的隐式依赖让维护成本直线上涨。

工程化思维兴起之后，“职责分离”成了铁律。前端负责展示和交互，后端负责数据和业务，中间用清晰的接口沟通。而 JSP 天然把两件事揉在一起，正好站在了这种趋势的对立面。

2.2 前后端分离浪潮到来，JSP 变成“异类”

2013 年之后，前端的技术演进明显提速。jQuery 时代还算温和，Angular、React、Vue 这些框架强势崛起，组件化开发、虚拟 DOM、单页应用（SPA）的概念开始深入人心。前后端团队逐步分家，后端只负责提供 JSON 数据接口，前端专注页面渲染和交互，再用 Nginx 做静态资源托管。

这种架构下，JSP 的存在感变得非常尴尬。服务端渲染的整页 HTML 无法直接用于 SPA，而且每个页面刷新都要向服务器发起一次完整请求，用户体验跟局部刷新、无感切换的 SPA 相比差距明显。移动端爆发更是加剧了这种趋势：同一个后端接口，可以同时服务 Web、iOS、Android，而 JSP 渲染的页面只能在浏览器里看，没法复用。

我身边一个很真实的例子是 2017 年前后，我们团队接手一个电商系统，后端 Java，前端原来是 JSP。业务方希望把移动端和 PC 端打通，讨论之后决定把 JSP 页面全部砍掉，后端改造出 REST API，前端用 Vue 重写。原因很简单：产品需要多端复用，JSP 的渲染结果根本供不上移动端使用。

2.3 性能、安全、生态三座大山

JSP 的硬伤还远不止架构层面的问题。先说性能：JSP 每次修改都要被容器重新编译成 Class，高并发场景下服务端渲染会持续消耗 CPU 来做字符串拼接与输出，而在前后端分离架构里，HTML、CSS、JS 都是静态文件，可以直接交由 CDN 缓存，API 层只传 JSON 数据，服务器压力不是一个量级。

再谈安全。JSP 里最常见的两个问题：一是页面直接拼 SQL，极易引发 SQL 注入；二是不做输出转义，用户输入原样渲染，XSS 攻击防不胜防。EL 表达式还出过非常严重的安全漏洞，攻击者可以通过精心构造的参数触发任意代码执行。再加上很多老项目把 JSP 文件放在可被直接访问的目录下，源码泄露的风险也始终存在。

生态方面，Spring Boot 时代到来之后，JSP 的处境变得更尴尬。Spring Boot 默认支持的是 Thymeleaf，官方文档对 JSP 的支持只停留在“可以跑，但你需要单独引入额外依赖、修改一堆配置”的程度。嵌入式容器（比如内嵌 Tomcat）对 JSP 的 JSTL 支持还存在各种坑，很多开发者在 Spring Boot 里鼓捣 JSP 失败之后，干脆转向 Thymeleaf 或直接上前后端分离。

“饿了么 element 图标前端 jsp”这个热词也很有意思。Element UI 是 Vue 的组件库，正常情况下它跟前端框架绑定。但当老项目的 JSP 页面需要融入新团队的视觉规范时，就会出现这种“在新工具链里找老页面素材”的错位感。这恰恰说明，JSP 的生态和现代前端工具链之间已经有了一堵明显的高墙。

2.4 人才断层：新人不学，老人不想写

技术被替代，人的因素也很关键。现在找一个愿意写 JSP 的 Java 开发者越来越难。新入行的程序员，培训机构教的是 Spring Boot、MyBatis、Vue，项目实训用的是前后端分离，没人教 JSP。

而写过 JSP 的老开发，转型之后也普遍不想再碰它。模板语法记得不多，JSP 特有的编译细节早就忘了大半，更关键的是，回到旧项目里写 JSP，意味着放弃现代开发体验：没有热更新、没有友好的调试工具、没有现成的组件库、没有单元测试覆盖。这种落差感，导致 JSP 的“存量开发者”也在加速流失。

结果就是恶性循环：新项目不用 JSP，新人就不学 JSP；没有人会 JSP，企业更不敢在新项目上用 JSP。技术就这样慢慢被边缘化了。

3. 别急着说再见：现在还在跑 JSP 的角落和求生指南

3.1 JSP 没死透，因为老系统还活着

虽然新项目里 JSP 基本绝迹，但遗留系统是个巨大的存在。银行、政务、传统制造企业里，很多 2010 年到 2015 年间建设的信息系统，至今还在生产环境上稳定运行。这些系统往往稳定、能跑、业务逻辑复杂，重构的风险远超收益，所以只能继续维护。

如果你现在被安排去维护这样的系统，JSP 的日常修修补补是逃不掉的。好在这类需求通常不会太复杂，比如热词里的“jsp个人信息展示页面”，本质上是一个老业务模块的小改动。

3.2 实操：在 JSP 里安全地做个人信息展示

假设你现在的任务是给一个老系统新增一个“个人信息展示页面”，后端用 Servlet，前端用 JSP。我建议的第一步，是把数据获取全部放到后台，不要在 JSP 里写任何一行 Java 逻辑。后台 Servlet 大致这样：

protected void doGet(HttpServletRequest request, HttpServletResponse response) { String userId = (String) request.getSession().getAttribute("userId"); UserInfo user = userService.getUserById(userId); List<OperationLog> logs = logService.listRecentLogs(userId, 10); request.setAttribute("user", user); request.setAttribute("logs", logs); request.getRequestDispatcher("/userInfo.jsp").forward(request, response); }

JSP 页面里只负责展示，全部使用 EL 表达式和 JSTL：

<%@ page contentType="text/html;charset=UTF-8" pageEncoding="UTF-8" %> <%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %> <html> <head> <title>个人信息</title> </head> <body> <div class="user-card"> <h3>${user.name}</h3> <p>邮箱：${user.email}</p> <p>手机：${user.phone}</p> <img src="${user.avatar}" width="80" height="80" alt="头像" /> </div> <h4>最近操作记录</h4> <table border="1" cellpadding="4" style="border-collapse:collapse"> <tr> <th>时间</th> <th>操作内容</th> </tr> <c:forEach var="log" items="${logs}"> <tr> <td>${log.operateTime}</td> <td>${log.content}</td> </tr> </c:forEach> </table> </body> </html>

这两块配合起来，页面职责清晰，也没有 SQL 拼接风险。有一点要特别提醒：老项目里经常在 JSP 里直接用<%= %>输出数据，但数据本身没做 HTML 转义，这是 XSS 的重灾区。推荐的做法是使用<c:out value="${user.name}"/>来输出，它默认会转义特殊字符。

3.3 实操：JSP 里的图片坐标定位怎么做

热词里有“jsp图片如何对坐标定位”，这个需求通常是给图片添加可点击区域，比如户型图上的房间、地图上的热点、产品图上的标签。JSP 里的实现思路跟纯 HTML 没什么本质区别，就是用<map>和<area>标签，只是区域坐标数据可以由后端动态生成。

假设你在做一个楼盘户型展示，后端返回了每个房间的坐标区域列表：

<img src="${housePlanImg}" usemap="#houseMap" alt="户型图" /> <map name="houseMap"> <c:forEach var="room" items="${roomList}"> <area shape="rect" coords="${room.x1},${room.y1},${room.x2},${room.y2}" href="${room.detailUrl}" alt="${room.name}" title="${room.name}" /> </c:forEach> </map>

这里的关键点在于坐标数据要从后端业务逻辑计算好再返回，不要在 JSP 里用大段 JavaScript 计算坐标。因为一旦把坐标计算逻辑塞进 JSP，后续调样式、调尺寸时就会牵一发动全身，维护难度成倍上升。

还有个常见的坑：如果图片是响应式布局，直接写死坐标会在缩放时偏移。老项目里最省事的方案是给<img>加固定宽度，或者在渲染时按实际显示比例换算坐标。换算逻辑放后端，前端只拿最终坐标。

3.4 实操：让 JSP 页面加载完自动刷新一次

热词“jsp页面让加载完后刷新一次”也是一个经典老需求，常见于数据展示大屏、监控页面、或者某些需要“进来就更新”的页面。实现方式有很多种，我最推荐的是放在body的onload事件里加延时刷新，避免一进页面就打转：

<body onload="setTimeout(function(){ location.reload(); }, 3000);">

如果你希望刷新得更干净，由服务器重新生成页面内容，可以在响应头里加 meta refresh：

<meta http-equiv="refresh" content="5">

但这里有个容易被忽视的坑：如果页面带表单且用户正在填写，自动刷新会把已填数据全丢。所以更稳妥的做法是给刷新操作加一个判断，只有页面中某个标识为真时才自动刷新。老项目里可以用 request 的 attribute 做控制：

<c:if test="${needAutoRefresh}"> <script> window.onload = function () { setTimeout(function () { location.reload(); }, 2000); }; </script> </c:if>

另外提醒一下，location.reload(true)这种强制从服务器加载的写法在老代码里很常见，但在现代浏览器里reload的参数基本被忽略，直接用location.reload()就好。

4. 还能怎么救：老 JSP 系统的渐进式改造路径

4.1 别想着推倒重来，先想共存

面对一个老 JSP 系统，最常见的冲动是“赶紧重新写一个”。但在银行、政务这种业务环境里，推倒重来 = 巨大的业务风险、数据迁移成本和测试成本。我更推荐的是渐进式改造，先让系统“一边跑一边瘦身”。

第一阶段，把 JSP 中乱七八糟的脚本片段清除掉，业务逻辑全部下沉到后台 Servlet 和 Service 层。JSP 只保留 HTML 展示、EL 表达式和 JSTL 标签。这个阶段不需要改架构，但维护体验会明显变好。

第二阶段，把纯展示的页面逐步迁移到 Thymeleaf。Thymeleaf 的语法跟 JSP 在思路上有些相似，同样支持服务端渲染，但它是自然模板，不需要引入额外的 JSP 容器支持，在 Spring Boot 里开箱即用，对开发工具的兼容性也好很多。

第三阶段，如果业务需要多端复用，再把核心模块的接口改造成 REST API，前端用 Vue 或 React 重写。但这一步不着急，按业务优先级逐个切换即可。

4.2 过渡方案：JSP 页面里局部调用 API

如果不想一次性改完，可以做一个折中方案：老的 JSP 页面继续跑，但页面中的部分区块改为通过 JavaScriptfetch调用后端接口来渲染。这种混搭模式虽然在架构上不“纯洁”，但在老项目改造过程中却非常实用。

<div id="latestOrders"></div> <script> fetch('/api/orders/latest', { credentials: 'same-origin' }) .then(function (response) { return response.json(); }) .then(function (data) { var html = '<ul>'; data.forEach(function (item) { html += '<li>' + item.orderNo + ' - ' + item.amount + '</li>'; }); html += '</ul>'; document.getElementById('latestOrders').innerHTML = html; }); </script>

这种做法的好处是风险可控：页面主体结构不变，只是局部用新接口替换旧渲染逻辑。等这一块的接口稳定了，后续再把整个页面迁到新前端框架，已经是水到渠成的事。

当然，混搭模式也有坑。老系统通常重度依赖 session，接口调用时一定要带上credentials: 'same-origin'，否则登录状态一丢，接口会全部返回 401。还有一处容易踩雷：老系统的接口返回值格式五花八门，有的是 JSON 包一层{code,msg,data}，有的直接返回数组，改造前先统一好接口格式，不然前端改起来很痛苦。

4.3 改造中的关键避坑点

老系统改造，最怕的就是“改一处坏一片”。我个人的经验是，动手前先做三类检查：

• 权限控制是否在 JSP 页面上做了硬编码，改造后会不会绕过原有权限逻辑。
• 接口依赖的 session、cookie 属性名是否改动，特别是跨模块共享的数据。
• 日志链路是否清晰，老系统很多磨人的问题都得靠日志定位，改造时要顺手把原先散落的日志串起来。

数据格式也要留意。老系统里日期往往是yyyy-MM-dd HH:mm:ss字符串，新接口如果返回时间戳，前端展示就会出偏差。金额字段老系统用 BigDecimal，但有的接口转成 String，有的转成 double，精度丢失的风险要提前评估。

5. 实战排雷：JSP 老项目最常见的几个疑难杂症

5.1 改了 JSP 页面死活不生效

这是 JSP 维护中出现频率最高的一个问题。明明改了文件，刷新浏览器却还是旧页面。原因基本是 Tomcat 的工作目录里保留了编译缓存。处理方式不复杂：找到 Tomcat 的work目录，把对应应用的编译产物清空，重启容器。

如果是在开发环境，可以把Context的reloadable属性设置为true，这样 JSP 修改后容器会自动检测并重新编译。但生产环境别这么干，动态热部署 JSP 在高并发下容易引发不可预期的问题，老老实实走发布流程。

5.2 EL 表达式取不到值

${user.name}渲染出来是空字符串，这个问题也很常见。排查方向有三个：先看 request 域里有没有这个 attribute 名；再看 JSP 页面开头有没有声明 JSTL 标签库；最后确认对象属性是否遵循了 JavaBean 规范。很多老代码在后台塞数据时用的是request.setAttribute("userInfo", user)，页面里却写${user.name}，不匹配自然取不到。

还有一种隐蔽情况：JSP 页面里同时存在脚本片段和 EL 表达式，脚本片段在页面顶部设置了局部变量，EL 表达式却取 request 域的值，两者互相干扰。这种代码在老项目里很常见，我建议遇到就直接把脚本片段删掉，统一用 EL。

5.3 中文乱码

老 JSP 项目的中文乱码，大概有四个来源：请求参数编码、响应输出编码、数据库连接编码、页面文件本身编码。排查时先看一眼 JSP 顶部的pageEncoding是不是 UTF-8，然后看 Servlet 里有没有设置response.setCharacterEncoding("UTF-8")，再看数据库连接串里有没有characterEncoding=UTF-8参数。

一个容易被忽略的地方是：老项目很多用的是 Tomcat 8 之前的版本，默认请求编码不是 UTF-8。如果改不了容器版本，可以在 Servlet 里全局加一个 Filter，把所有请求和响应的编码统一设置为 UTF-8。

5.4 常见问题速查表

这堆问题我在老项目维护里基本都撞过一遍。最磨人的不是技术难度，而是老代码里的“历史包袱”导致错误定位困难。遇到问题别急着改代码，先加日志、抓包、看浏览器的 Network 面板，把问题范围缩小到某一层再动手。

我的一点真实感受

最后一次正经写 JSP，是帮一个老系统加一个报表导出功能。前后忙了两个小时，大部分时间不是在写代码，是在跟它的脚本片段纠缠。修好那一刻，我心里没有成就感，反而有点感慨：技术没有绝对的优劣，只有跟时代的匹配度。JSP 陪很多人走过了 Web 开发最粗粝也最有生命力的阶段，它确实老了，但还没完全退场。如果你恰好还在维护 JSP 老项目，别急着全盘否定它，跟随系统先跑稳、再一步步改造，守住稳定，再图创新，这才是对老系统负责任的态度。