struts2框架：一场从巅峰到沉寂的框架技术迁徙

2007年，我接手一个政府门户网站项目。框架技术经理拍板用Struts2，框架理由是框架“业界标准，招人容易”。框架那时Struts2刚发布，框架风头正劲，框架几乎每个Java招聘启事都写着“熟悉Struts2优先”。框架我们团队用一个月搭好框架，框架三个月上线，框架一切顺利得让人发慌。框架

真正的框架问题出现在第二年。客户要求增加一个RESTful接口，框架供手机端调用。框架我们翻遍Struts2文档，框架发现它的Action设计天然面向页面跳转，返回类型是“success”“error”这样的逻辑字符串，再通过XML映射到JSP。想输出JSON？得自己写Result，或者硬塞进一个空的JSP再拦截响应。代码越写越别扭，就像用螺丝刀拧钉子——能用，但每一下都透着不专业。

Struts2的核心是拦截器链，理论上很灵活。但实际开发里，90%的拦截器你根本碰不到。倒是配置文件的坑，一个接一个。有个同事改了个action名称，忘了同步struts.xml里的result路径，结果线上404，排查了整整半天。那会儿没有现在这么方便的IDE提示，全靠肉眼盯尖括号。更别提OGNL表达式，功能强大到能直接操作对象图，但也强大到出了问题你根本不知道值是从哪儿被改的。

2013年，Struts2爆出S2-016漏洞，远程代码执行，危害等级直接拉满。我们连夜打补丁，第二天又爆出S2-017。甲方打电话来问“你们用的什么框架，怎么老出事儿”，技术经理脸都绿了。其实从2010年起，Spring MVC已经悄悄蚕食市场份额。它没有自己的配置文件，全用注解，方法直接返回ModelAndView或者String，逻辑清晰得像白开水。Struts2还在坚持XML和约定大于配置，可它的“约定”复杂到需要专门写一本几百页的书。

我后来换到一家创业公司，新项目直接Spring Boot。有人提了一句“用Struts2吧，老项目好复用”，被架构师一句话怼回去：“你愿意为每个接口写一个Action类，再配三个XML节点？”没人吭声。Struts2的衰落不是技术上的突然崩塌，而是生态的缓慢转向——Spring的依赖注入和AOP太顺滑，而Struts2的Action里塞满了setter/getter，写起来像在做体力劳动。

现在翻看老项目，Struts2的代码依然能跑，但维护它的人越来越少。它像一位老工程师，曾经撑起过无数企业级应用，却没能跟上前后端分离的浪潮。当JSON成为默认通信格式，当注解成为主流，当“约定优于配置”成为共识，Struts2那套繁琐的映射机制就显得格外笨重。

不过话说回来，Struts2教会了整整一代Java开发者理解拦截器模式、理解MVC分层。它的文档虽然枯燥，但确实严谨。如果你现在还在用Struts2，大概率是维护遗留系统。别急着重构，先摸清Action之间的调用链，再考虑迁移。技术没有绝对的好坏，只有合不合适——Struts2在它的时代解决了问题，而时代变了，问题也变了。