2003年，站开我在一个企业内网项目里第一次用JSP。站开那时候ASP还在流行，站开PHP正爬坡，站开JSP靠着Java的站开牌子硬生生挤出了一条路。二十多年过去，站开JSP没死，站开但活得很安静——新项目几乎没人主动选它，站开可你打开任何一家银行、站开保险、站开政府机构的站开旧系统，十有八九还能翻出几个.jsp文件。站开这东西就像老式手动挡汽车，站开不时髦，站开但能跑，站开修起来还便宜。

JSP的本质其实特别简单：一个HTML文件里嵌入Java代码，服务器把它编译成Servlet，然后输出纯HTML给浏览器。就这么个机制。你写<% out.println("hello"); %>，Tomcat在背后把它翻译成out.write("hello");，再包一层Servlet的壳。第一次访问慢，因为要编译，之后就快了。这个设计在2000年代初很聪明——前端不用学新东西，后端Java程序员直接写页面，省了分工成本。

但问题也出在这。业务逻辑和展示逻辑搅在一起，一个页面几百行，改个按钮颜色得翻半天Java代码。我见过最夸张的一个JSP文件，三千多行，里面既有数据库查询，又有JavaScript表单验证，还有CSS样式。维护那个文件的哥们说，每次改需求他都想辞职。

所以后来有了MVC。Struts、Spring MVC把JSP降级成纯视图层，只负责拿数据渲染。这个思路是对的。<c:forEach>标签取代了<% for(...) %>，EL表达式${ user.name}取代了<%= user.getName() %>。代码干净了不少。但说实话，JSP标签库那套东西学起来也不轻松，而且调试麻烦——报错信息经常指向编译后的Servlet，跟你写的JSP对不上号。

现在做新项目，我基本不推荐JSP。前后端分离是大势，Vue、React负责界面，Spring Boot只吐JSON，职责清晰，部署也灵活。JSP适合什么场景？小型内部工具、遗留系统维护、教学演示。我带实习生的时候还会让他们写几个JSP页面，目的是理解HTTP请求响应周期和Servlet容器的工作原理。理解了底层，再用框架就不会飘。

有个细节值得说：JSP的九大内置对象——request、response、session、application、out、page、pageContext、config、exception——这些名字现在看很朴素，但它们把Web开发的核心概念全摊开了。request管请求参数，session管用户状态，application管全局共享。你把这些搞明白，再去看Spring的@RequestParam、HttpSession，会发现只是换了个皮。

Tomcat对JSP的支持一直很稳。你放个index.jsp在webapp目录下，启动就能访问。不需要额外配置。这种零门槛的部署体验，在容器化时代反而成了优点——一个war包扔进去，什么都不用管。Docker里跑个Tomcat镜像，挂载webapps目录，五分钟搞定。比配Nginx加Node环境省事多了。

最后说句实在的：JSP不是好技术，但它是个有用的技术。你知道它怎么运作，知道它哪里疼，知道什么时候该用它、什么时候该绕开，这就够了。技术选型从来不是选最好的，是选最合适的。旧系统里那些JSP页面还在跑，说明它们解决了问题。新项目不用它，说明有更好的方案。就这么回事。