内容摘要：2007年，我接手一个老项目，web.xml里赫然写着Struts2的FilterDispatcher配置。那时候Spring MVC还没一统天下，Struts2就是Java Web开发的主流选择。A

2007年，我接手一个老项目，web.xml里赫然写着Struts2的FilterDispatcher配置。那时候Spring MVC还没一统天下，Struts2就是Java Web开发的主流选择。Action类继承ActionSupport，方法返回String，struts.xml里配result跳转——这套流程当年写起来顺手得很。

Struts2的核心设计其实不复杂。它用Filter拦截所有请求，根据struts.xml或注解找到对应的Action类，调用execute方法，再根据返回值决定跳哪个页面。OGNL表达式贯穿其中，参数绑定、类型转换、校验都靠它。值栈（ValueStack）这个概念当时觉得挺巧妙，Action的属性和请求参数放在一起，JSP里直接写<s:property value="userName"/>就能取到值。

但问题也出在这里。

OGNL给了太多自由，也埋了太多雷

Struts2允许在参数名里写OGNL表达式。比如提交一个名为user.name的参数，框架会自动调用getUser().setName()。这个机制叫“参数注入”，本意是方便，结果成了无数漏洞的源头。2013年到2017年间，S2-016、S2-032、S2-045、S2-052……远程代码执行漏洞一个接一个。攻击者构造恶意Content-Type头，或者往参数名里塞OGNL表达式，就能在服务器上执行任意命令。

我印象很深的是S2-045。漏洞公开那天，公司安全团队直接拉了紧急会议。排查下来，十几个系统还在用Struts2，版本从2.3.15到2.3.28不等。升级？有些项目连构建脚本都跑不起来了，JDK版本、依赖冲突，改一天改不完。最后只能先在WAF上加规则拦截，再排期慢慢升。

那段时间，Struts2在技术圈的名声基本毁了。每次出漏洞，安全圈就调侃“Struts2又双叒叕出事了”。开发者也开始用脚投票，新项目几乎没人再选它。

它并非一无是处，但时代确实过去了

公平地说，Struts2的拦截器机制设计得不错。日志、权限、事务这些横切逻辑，用拦截器栈串起来，配置清晰。国际化支持也完善，资源文件一放，切换语言就几行配置。标签库虽然笨重，但在JSP时代确实省了不少HTML代码。

可这些优势在Spring MVC面前逐渐失色。Spring MVC的DispatcherServlet更轻，注解驱动开发更直观，和Spring生态无缝集成。Struts2的配置要么堆在XML里，要么用Convention插件靠约定，都不如@Controller和@RequestMapping来得干脆。

更致命的是社区活力。Spring一直在迭代，Struts2的更新节奏明显慢了。Apache基金会后来把Struts项目降级到“休眠”状态，虽然偶尔还有安全补丁，但功能层面基本停滞。

现在回头看，Struts2像是一个特定时期的产物。它解决了MVC分层的问题，却在安全设计上留了太多口子。它让Java Web开发变得有章可循，却没能跟上轻量级、注解化、微服务化的趋势。

如果你现在维护的老系统里还有Struts2，第一件事是查版本号。2.5.30以上相对安全，但最好还是规划迁移。如果新项目要选型，直接跳过它。技术选型有时候就是这样——不是它不够好，而是有更合适的选择，而且那些选择没有一堆CVE挂在身上。

我最后一次写Struts2的Action是2015年。那个项目后来重构成了Spring Boot，Action类变成了Controller，struts.xml删了，值栈没了，OGNL也换成了SpEL。代码量少了三分之一，启动速度快了一倍。没人怀念Struts2。