上周五晚上九点多，一个朋友打电话过来，说有个老系统页面报错，让我帮忙看一眼。我远程连上去，Tomcat 控制台刷了一屏异常，项目目录里整整齐齐躺着一排 .jsp 文件。那一刻我忽然意识到，我已经很久没有在一个新建项目里见过 JSP 了。仔细想想，十年前我刚入行那会儿，JSP 就是 Java Web 的代名词，简历上不写一句"熟悉 JSP/Servlet"都不好意思投后端岗。现在呢？新项目里清一色前后端分离，服务端模板要么选 Thymeleaf，要么干脆连模板都省了，直接返回 JSON。这篇文章我就想结合自己这些年维护老系统、做新项目的实际经历，聊聊 JSP 到底是怎么从"风光无限"走到"很少有人主动选它"这一步的，也顺便说说那些还在运行、还在被搜索的 JSP 页面，今天到底该怎么维护。
1. 缘起：一次老项目救火，让我重新审视 JSP
1.1 目录里的"文物"：那些年我们写过的典型 JSP
先说那天晚上我看到的那个页面。十来年没动过的 OA 系统，典型的 SSH 框架组合，目录里按模块堆了一大堆 .jsp 文件。我随手点开一个列表页，画风是这样的：
<%@ page contentType="text/html;charset=UTF-8" language="java" %> <%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %> <html> <head> <title>员工列表</title> <style> table { border-collapse: collapse; } td { padding: 6px; border: 1px solid #ccc; } </style> </head> <body> <% List<Employee> list = (List<Employee>) request.getAttribute("employeeList"); if (list != null) { for (Employee e : list) { %> <tr> <td><%= e.getName() %></td> <td><%= e.getDept() %></td> <td> <a href="edit.jsp?id=<%= e.getId() %>">编辑</a> <a href="javascript:void(0)" onclick="del(<%= e.getId() %>)">删除</a> </td> </tr> <% } } %> </body> </html>这段代码放在今天看，槽点非常密集：HTML、CSS、Java 脚本、JSP 标签、还有最底下的 JavaScript onclick 全部揉在一个文件里。前端同事看不懂那堆<% %>，后端同事改起 CSS 也头疼。最麻烦的是，这样一个页面文件既是模板又是逻辑又带数据库查询结果渲染，谁接手都得先花半天在各种标签和脚本之间做阅读理解。我当时在电话里跟朋友说，这页面报错其实不是因为它坏了，而是因为它承载了太多不该它承载的东西——这句话放在整个 JSP 的命运里也成立。
1.2 JSP 是怎么做到"风光无限"的：它确实是Servlet的官方替代品
不过话说回来，JSP 能火十几年，完全是靠实力打出来的。当年 Java Web 的另一个选择是纯 Servlet，你要用 Servlet 输出一个表格，代码大概长这样：
response.setContentType("text/html"); PrintWriter out = response.getWriter(); out.println("<html>"); out.println("<head><title>员工列表</title></head>"); out.println("<body>"); out.println("<table>"); for (Employee e : list) { out.println("<tr>"); out.println("<td>" + e.getName() + "</td>"); out.println("<td>" + e.getDept() + "</td>"); out.println("</tr>"); } out.println("</table>"); out.println("</body>"); out.println("</html>");每写一行 HTML 都要套一层 out.println，字符串拼接、引号转义，写多了人真的会疯。JSP 的思路恰好反过来：把页面当成一个 HTML 模板，在里面嵌 Java 逻辑，交给服务器去翻译执行。这样页面设计师可以专注写 HTML，Java 程序员只管往指定位置塞数据。1999 年 Sun 推出 JSP 1.0，等于给所有被 Servlet 折磨的 Java Web 开发者一个官方出路，加上后来 JSTL 标签库、EL 表达式的补充，JSP 逐渐成了 Java 企业级应用的事实标准。
1.3 为什么我现在很少在新项目里主动提起它
说白了，JSP 不是一夜之间失宠的，是一次一次的技术选择把它推到了边缘。我后来负责的几个新项目，架构评审的时候几乎没人再提 JSP，默认方向就是"后端做 REST API，前端用 Vue 或者 React 自己搭"。开技术会议的时候，谁要是提议"新系统用 JSP 渲染页面"，大家的表情大概就跟看到有人推荐用 IE6 调试前端一样。这里面有技术层面的原因，也有整个软件工程分工演进的原因。下面几章我把这些原因拆开讲清楚，你会发现 JSP 的没落并非技术倒退，恰恰是工程理念向前走了一大步的必然结果。
2. 拆开 JSP 的"壳"：设计逻辑与天生局限
2.1 JSP 的执行链路：翻译、编译、再执行
要理解 JSP 为什么维护起来费劲，得先弄明白它被请求时发生了什么。JSP 文件并不是被浏览器直接执行的，它是一次正经的"服务端翻译+编译"过程：
- 浏览器请求 index.jsp，Tomcat 容器收到请求；
- 容器先检查 JSP 对应的 Servlet 源码是否存在、是否比 JSP 文件旧；
- 如果过期或不存在，就把 index.jsp 翻译成一个 Java 文件（比如 index_jsp.java），这个翻译过程会把你写的标签、脚本代码全部转成 Java 源文件；
- 紧接着 javac 把它编译成 class；
- 容器加载这个 class，实例化成 Servlet，调用它的 service 方法执行，最终把 HTML 响应写回浏览器。
这个过程意味着什么？意味着 JSP 页面本质上是"程序员以为自己在写模板，实际上每改一次都可能触发一次编译流程"。开发期这很方便，改完 JSP 刷新页面就行，不用重启项目；但生产环境就有隐患了，JSP 文件被意外覆盖、容器缓存的旧 class 没有清理，导致"改了没生效""发布后线上还是旧页面"之类的诡异问题，我在维护期真的没少遇到。
2.2 模板与脚本的边界：EL 和 JSTL 为什么没能拯救 JSP
很多人会说，JSP 后来不是有 EL 表达式和 JSTL 标签库吗？逻辑不是可以抽到 Servlet 或者 Action 里吗？确实，JSP 2.0 引入 EL 和 JSTL 之后，Java 脚本块在正规项目里被明令禁止，页面代码清爽了不少。但问题在于，EL 和 JSTL 解决的只是"页面里还能不能写 Java 代码"的表面问题，JSP 的核心编译模型和容器耦合没有变。
换句话说，你用 JSTL 写一个循环，出错了它依然会抛出一长串跟 JSP 翻译后 Java 文件相关的堆栈；你用 EL 取值取不到，页面上就是一片空白，不报错也不提示，全靠自己猜变量名是不是写错了。模板语言本身的"宽容"在这里反而成了调试负担。而且 JSP 页面无法脱离 Web 容器独立运行，你没法像打开一个普通 HTML 文件那样在浏览器里直接预览 JSP 模板，必须启动 Tomcat、部署项目、访问 URL，每验证一次都带着重量级上下文。
2.3 "JSP 页面让加载完后刷新一次"背后：请求-响应模型的局限
我记得一个很有意思的搜索热词是"jsp 页面让加载完后刷新一次"，这背后其实就是 JSP 最典型的困境。在 JSP 时代，页面是"一次请求生成一次完整 HTML"的模型，服务端把所有数据塞进页面，然后一次性吐给浏览器。如果加载后需要自动刷新，要么在页面里加<meta http-equiv="refresh" content="...">，要么写一段 JavaScriptlocation.reload()，但这会带来一个尴尬问题：如果服务端渲染出的页面数据是旧的，刷新一下也还是按旧数据重新渲染；如果页面里有什么状态，刷新一次可能就给刷丢了。
这个问题的根源在于 JSP 天生是"服务端主动渲染、浏览器被动接收"的模型。页面的局部更新、状态保留、即时反馈这些交互需求，在 JSP 体系里不是不能做，而是做起来特别别扭，要靠 AJAX、jQuery 插件、各种手写的 JavaScript 去补。而当整个行业转向前后端分离之后，这些交互能力不再需要服务端模板操心了，浏览器端框架一手包办，JSP 自然就退出了"交互页面渲染"这个主战场。
3. 真正劝退开发者的是这三个硬伤
3.1 维护成本：一个 JSP 文件里什么都有，于是什么都难改
我在 1.1 节展示的那段代码，其实还只展示了静态部分。真实项目里的 JSP 文件往往更长，顶部是 page 指令、include 指令、taglib 声明，中间夹着若干段 Java 脚本或者 EL 表达式，HTML 结构里又嵌套 JavaScript，JavaScript 里面又拼接了一堆 JSP 变量。这样一份文件，它既是结构、又是样式、又是逻辑、又是数据。
维护这样的文件有一个特别消耗团队协作成本的问题：职责划分不清楚。前端工程师想在 JSP 里改个样式，得小心翼翼别碰那些<% %>标签；后端工程师想改个列表排序逻辑，又怕动到 HTML 结构；如果项目组里没有"谁都能改 JSP"的全栈型选手，最简单的改动都要拉着两个人一起上。编译期还没有任何检查，EL 表达式拼错一个字母，页面运行时不报错，只显示空白，等你发现往往已经在生产环境了。这种"改起来胆战心惊、出问题排查困难"的体验，放到任何一个追求效率的开发团队里，都是第一优先级要抛弃的。
3.2 调试体验：错误行号指向的是生成的 Java 文件
JSP 调试有多痛苦，经历过的人都懂。JSP 报错的时候，Tomcat 日志里的异常堆栈通常长这样：
org.apache.jasper.JasperException: Unable to compile class for JSP An error occurred at line: [23] in the generated java file: [D:/apache-tomcat-8.5/work/Catalina/localhost/app/org/apache/jsp/index_jsp.java]注意，这个 "line: [23]" 指的是容器翻译出来的 Java 文件第 23 行，不是你写的 JSP 文件第 23 行。你也得顺着找到 work 目录下的 index_jsp.java，把 JSP 源码和翻译后的 JS 代码对照着看。如果只是编译错误还好，最怕的是 NullPointerException、ClassCastException 这类运行期错误，堆栈里全是_jspService方法里各种变量转换，你根本不知道是页面里哪一行request.getAttribute把类型搞错了。我维护老项目时，遇到过一次<%= list.get(0).getName() %>在 JSP 里取不到值，排了大半天，最后发现是 Action 往 request 里放 attribute 时 key 拼错了一个字母，而 EL 表达式取不到值又不会给你任何明显提示。
这种调试体验放在今天确实没法忍。现在的模板引擎或者前后端分离方案，要么有明确的变量类型约束，要么浏览器开发者工具直接告诉你接口返回了什么、字段哪里不对，哪像 JSP 这样中间隔着一层编译转换，错误信息被层层包装。
3.3 性能与发布：动态渲染、首次编译、静态化无力的组合拳
JSP 在性能上也不是没有短板。它每次请求都是动态渲染的，服务端要把模板编译后的 Servlet 跑一遍，访问数据库也好、拼接 HTML 也好，都比纯静态页面慢一个量级。虽然有 JSP 预编译技术可以在构建期把页面编译好，但预编译只是解决"首请求慢"这一个问题，页面本身依然是每次动态生成。
更尴尬的是静态化能力。JSP 页面动态生成的内容没法直接扔给 CDN，哪怕你的首页内容其实是三天才变一次，也不得不老老实实走服务端渲染流程。而今天的前端方案，构建产物是一堆静态 JS/CSS/HTML，直接往 Nginx、OSS、CDN 一放，首次访问快、并发扛得住、回源成本低。再加上 JSP 官方标准为了兼容老特性，指令、动作、脚本元素、EL、JSTL 五套语法各占一块，新上手的人看到<%! %>、<%= %>、${}、<c:forEach>混在一起，光是搞清楚该用哪种写法就够喝一壶的了。
4. 压垮 JSP 的时代浪潮：前后端分离与技术栈重构
4.1 移动互联网把 HTML 从"唯一答案"变成了"可选答案"
JSP 时代有一个默认前提：用户想看什么，服务端就渲染什么 HTML。这个前提在 PC 互联网时代基本成立，但到了移动互联网时代被彻底打破了。同一个后端服务，要同时给 PC 网页、手机网页、iOS App、Android App 甚至未来的小程序供数据，这时候"服务端返回一整张 HTML 页面"就不合用了，App 需要的是一份结构化的数据，比如 JSON，由客户端自己决定怎么展示。
我印象很深，大概是 2013 年之后，我所在的项目组陆续开始"接口化改造"，服务端不再用 JSP 把页面渲染好了再返回，而是提供/api/getEmployeeList这类接口返回 JSON，前端网页用 AJAX 拉取。JSP 在这种场景里越来越像个多余的角色：如果页面要做动态渲染，前端 JS 可以自己拼 DOM，后端没必要管 HTML 结构；如果页面足够简单，那用纯 HTML+静态资源也够了。服务端渲染方案从"必须"变成了"可选"，而 JSP 这个可选方案还带着编译模型、容器依赖这些历史包袱，自然就被边缘化了。
4.2 前端工程化成熟：浏览器能做的事比想象中多
前后端分离之所以能成气候，还得益于前端工程化本身的突飞猛进。Vue、React、Angular 这些框架把页面拆成组件，数据流、状态管理、路由全部可以在浏览器端解决；Webpack、Vite 又把资源打包、代码压缩、按需加载这些事标准化了。我后来在新项目里写页面，几乎不再碰服务端模板，后端只负责数据接口和权限校验，前端团队自己维护一套前端工程，上线时把构建产物丢到静态服务器就行，效率和维护体验都远胜当年在 JSP 里倒腾。
这样一来，JSP 的定位就非常尴尬了。它身上的标签是"服务端渲染、Java 语法、依赖容器"，恰好都是前端工程化浪潮中想要甩掉的旧概念。更关键的是，开发团队的人员结构变了：前端工程师不再需要懂 Java，后端工程师也不需要再写模板代码。JSP 让两类人挤在一份文件里的协作模型，本身就是跟不上分工细化趋势的。
4.3 服务端渲染并没有消失：JSP 的接盘者们
需要说明的是，JSP 倒下了，不代表服务端渲染这个思路也倒下了。在一些需要 SEO、首屏速度极快的场景里，服务端渲染依然是合理选择。JSP 的继任者们在设计上显然吸取了它的教训，我列个表对比一下会更直观：
| 方案 | 是否依赖 Java 容器 | 浏览器直接预览模板 | 调试体验 | 主要适用场景 |
|---|---|---|---|---|
| JSP | 必须部署在 Tomcat/Jetty 等容器 | 不能，必须启动项目访问 | 出错看编译后 Java 文件，体验差 | 老存量系统 |
| Thymeleaf | 不强制，Spring Boot 可直接集成 | 能，模板本质是合法 HTML | 属性绑定出错时提示相对明确 | 新后端渲染项目、邮件模板 |
| Freemarker | 不强依赖容器 | 能，但语法不是标准 HTML | 比 JSP 好定位，但也是文本模板 | 邮件、静态化页面生成 |
| Vue/React SPA | 不依赖 Java，构建产物纯静态 | 能，整个项目就是静态资源 | 浏览器开发者工具直接定位 | 绝大多数新项目 |
尤其是 Thymeleaf，它跟 Spring Boot 配合得很顺，模板本身就是合法的 HTML 文件，浏览器直接双击就能看到静态原型，服务端渲染时用 th: 开头的属性绑定数据，出错了也能比较快定位到具体对象的哪个字段名写错。对比 JSP 那套 "HTML 里嵌<% %>" 的语法，Thymeleaf 至少做到了"模板是模板，逻辑是逻辑"，所以它能在 JSP 失势的这些年接住很多原本属于 JSP 的场景。
5. 可现实是：JSP 还没死透，搜索热词暴露了幸存者的难处
5.1 "jsp 图片如何对坐标定位"：老系统的交互需求如何解
写这篇文章之前，我去翻了下近期跟 JSP 相关的搜索热词，发现一个很有意思的组合："jsp 个人信息展示页面""jsp 图片如何对坐标定位""jsp 页面让加载完后刷新一次""饿了么 elment 图标前端 jsp"。这些词暴露了一个真相：JSP 没有完全消失，它只是退守到了一批存量系统里，而维护这些系统的人，还在用十年前的思路解决今天的交互问题。
先说"图片坐标定位"。这种需求在 JSP 时代非常典型，比如后台管理系统里要在一张区域图上标注点位，或者在图片上圈出几个热区，点击之后把坐标回传给服务端。老派做法是在 JSP 页面里用<map>标签配<area>热点，或者用 JavaScript 监听点击事件，然后把坐标埋进表单提交到 JSP 页面，服务端再用request.getParameter("x")去拿。写起来很绕，而且一旦要动态增删热点，JSP 里就得反复拼接字符串标签，维护体验很差。
实际上这类交互逻辑就该在前端完成：坐标的计算、热区的渲染全部在浏览器里做，JSP 最多负责输出一个容器节点，服务端只需要给一个接收坐标的接口就够了。如果你现在还在维护 JSP 老系统，尽量把坐标判断这类逻辑往前端挪，不要在 JSP 脚本里硬算，不然每次改都要重新编译不说，定位问题还是老一套的痛苦。
5.2 "jsp 页面让加载完后刷新一次"：缓存与刷新困境
"jsp 页面让加载完后刷新一次"这个词能成为搜索热词，我一点都不意外。老系统里经常出现这种场景：后端改了点数据，但是页面因为缓存还展示旧内容，或者 JSP 页面里有一段代码必须等页面加载完再触发某个统计。很多人的第一反应是加<meta http-equiv="refresh" content="0">或者window.location.reload()，但这属于治标不治本，甚至会让页面陷入"加载完就刷新、刷新完又加载"的循环。
更好用的思路是区分"刷新的原因"。如果是为了让浏览器拿到最新数据，正确做法是在服务器响应里控制缓存，比如在 JSP 页面顶部用 response 对象设置缓存头：
<% response.setHeader("Cache-Control", "no-cache, no-store, must-revalidate"); response.setHeader("Pragma", "no-cache"); response.setDateHeader("Expires", 0); %>如果是因为页面里某个异步操作需要在 DOM 加载完之后再做，那就在静态 JS 文件里用window.addEventListener('DOMContentLoaded', ...)，别把这个逻辑也塞进 JSP。说白了，这些老问题其实都有现代解法，难点不在于技术，而在于维护者习惯了 JSP 时代的"一把梭"，把页面刷新、数据加载、状态更新全混在一个动态渲染模型里去处理。
5.3 "饿了么 elment 图标前端 jsp"：老页面迎娶新组件
还有一个挺有代表性的热词："饿了么 element 图标前端 jsp"。Element UI 是 Vue 生态里的组件库，跟 JSP 本来是两个时代的东西，但在真实项目里，这两个时代确实会在同一张页面里并存。我见过不少存量 JSP 项目，底部或者某一块区域被改造成了 Vue 局部组件，页面外壳还是 JSP 渲染的，但中间的内容区域已经用上了 Element 的表格、弹窗、表单校验。
这种混合模式其实是一种非常务实的过渡方案。如果你不想推翻整个老系统，又想在 JSP 页面里用上现代组件库，可以只在一个 div 上挂载 Vue 实例，让 JS 部分用 Element 重写，数据通过接口从后端拿。JSP 承担它最擅长的事：输出页面骨架、处理会话和权限校验；剩下的交互交给现代前端。这样既不违背"新代码别写进 JSP"的原则，又能在存量系统里逐步提升体验。
6. 如果今天还要维护 JSP，我的几点建议
6.1 新代码不进 JSP：在存量系统里划出安全区
我在前面反复强调一个原则，这里再说得直接一点：如果是维护老系统，你没法让所有 JSP 一夜之间消失，但你完全可以管住自己的代码习惯，做到"新代码不进 JSP"。具体来说，数据准备全部放在 Controller 或者 Action 里完成，页面里的 JSP 只允许用 EL 表达式和 JSTL 标签输出数据，禁止再新增<% %>脚本块。新增功能尽量做一个独立的静态页面或者挂载一个 Vue 实例，而不是在老 JSP 文件里继续叠代码。
这么做的好处是，当你后续决定为这个模块做重构时，改动边界是清晰的。你不需要理解一堆 JSP 脚本页面的历史逻辑，只需要把 Controller 的数据接口暴露出来，再把页面外壳用新模板替换掉就行。划定安全区，是让一个老系统"活到退休"而不是"带病恶化"的关键。
6.2 性能抢救：预编译与缓存策略
如果系统响应已经明显变慢了，除了加服务器资源之外，JSP 本身也有几件能立刻做的事。第一是预编译，Tomcat 提供了 JspC 工具，可以在构建期把 JSP 全量翻译编译好，部署之后就不用等首次访问的编译时间，对那种"线上有个页面第一次打开要好几秒"的问题立竿见影。第二是设置合理的页面缓存，把不常变动的 JSP 页面通过响应头设置浏览器缓存，或者把高频访问的列表页生成静态 HTML 文件落盘，反向代理直接读静态文件，绕开 JSP 的动态渲染。第三是把页面里的 jQuery、图片、字体这类静态资源挪到独立域名或者 CDN 上，至少别让 Tomcat 在处理业务请求的同时还要扛静态资源。
6.3 团队与技能：JSP 老系统的"毕业路径"
最后说说团队层面的问题。现在的新人几乎不学 JSP，校招简历上写的都是 Spring Boot、Vue、React，这是大势所趋。你不可能要求新人花大量时间去学一套已经边缘化的模板技术，所以老系统的维护策略得是"尽量减少 JSP 在系统里的存在感"。
我的建议是走渐进式重构的路径，而不是推倒重来。先接口化：把页面上取数的逻辑改成调后端 JSON 接口，让业务逻辑和视图层解耦；再试图层替换：挑一个最容易出问题的模块，用 Vue/React 或者 Thymeleaf 先重做这一块页面，验证流程跑通；最后再考虑让整个系统退役 JSP。这样每一步都是可逆的、可交付的，不用一次性承担巨大的重构风险。我在前几年帮一个朋友团队做过类似的迁移，花了三四个月，把核心模块从 JSP 迁到了前后端分离的架构，最后剩下的 JSP 文件基本只剩一些没太多人访问的历史页面，系统本身的维护成本和开发效率都明显改善了。
如果你现在也守着一套还在跑的 JSP 系统，别急着骂它落后。它曾经也是那个时代里最合理的工程方案，扛过多少业务、积累了多少数据，只有一路维护过来的人才知道。只是整个行业已经换了思路：服务端不再负责产出页面，而是负责把数据做稳、做准，表达和交互交给更专业的前端技术栈。JSP 的退场，不是因为写它的那批人不努力，而是因为软件工程本身又在往前走了。
