2017年8月，一个叫Struts2的老牌Java Web框架被爆出史诗级漏洞，代号S2-045。黑客只需向服务器发送一个精心构造的Content-Type头，就能直接远程执行任意命令，拿下整台服务器。当时全球有超过65%的Java网站使用这个框架，包括不少航空、银行和电商系统。有安全团队做了一次扫描，仅中国地区就有上万台服务器在数小时内被批量植入后门。那次事件后，很多老程序员开始认真思考一个问题：我们是不是过度依赖某个框架了？

Struts2的故事要从2001年说起。当时Java Web开发还处于Servlet+JSP的原始时代，程序员得手动处理每个请求参数，写一堆样板代码。有个叫Craig McClanahan的老哥搞了个Struts 1，把MVC模式引入了Java Web世界。这个框架火到什么程度？2003年时，几乎每个Java招聘启事上都写着"熟悉Struts优先"。但Struts 1有个硬伤——它的Action是单例的，所有请求共享一个实例，线程安全问题全靠程序员自己背。后来WebWork框架横空出世，用拦截器机制解决了这个问题，还引入了依赖注入。2005年，两个项目合并，Struts2诞生。

Struts2的架构确实漂亮。它把请求处理流程拆成一条拦截器链，每个拦截器只干一件事：参数解析、文件上传、表单校验、国际化……开发者可以灵活组合这些拦截器，像搭乐高一样构建自己的业务逻辑。这种设计在当时非常超前，比Spring MVC的HandlerInterceptor要灵活得多。但问题恰恰出在"灵活"上——OGNL表达式语言是Struts2的核心，它允许请求参数直接绑定到Java对象的属性上，甚至能调用静态方法。这就像给了黑客一把万能钥匙，只要参数校验稍有不慎，OGNL表达式就能注入到服务器端执行。S2-045漏洞的根源，就是框架在处理文件上传时错误地解析了Content-Type头，把它当作OGNL表达式执行了。

从S2-001到S2-061，Struts2几乎每年都要爆出几个远程代码执行漏洞。有人统计过，从2007年到2020年，官方发布的漏洞公告超过50个。社区里流传着一句话："Struts2的漏洞不是修出来的，是攒出来的。"这话虽然有点偏激，但反映了现实——框架为了保持兼容性，不敢轻易改动底层实现，导致老漏洞修了，新攻击面又冒出来。我认识一个运维大哥，他负责的系统用了Struts2十年，每次漏洞公告出来都得熬夜打补丁，后来干脆写了个自动化脚本，每天检查官方安全公告。

到2018年，Spring Boot开始大行其道，很多新项目直接绕开了Struts2。它的维护者也逐渐放慢了更新节奏，2020年后基本只剩安全修复。但Struts2并没有彻底消失，大量遗留系统还在运行，尤其是金融和政府项目，牵一发动全身，没人敢轻易重构。这让我想起一个比喻：Struts2就像一栋老房子，装修气派、结构复杂，但管道老化严重。你知道该翻新，可住户太多，搬家成本太高，只能修修补补继续住。

现在回头看，Struts2的兴衰给技术选型敲了一记警钟。框架的流行程度不等于它的安全程度，灵活性往往意味着攻击面更大。当年选择Struts2的团队并非不谨慎，只是那时候没有更好的选择。技术世界里没有永恒的赢家，只有不断演进的风险。今天用Spring Boot的开发者，或许也该想想——十年后，这个框架会不会也被某篇安全公告钉在耻辱柱上？