Struts框架死了吗？框架没死。但它在Java Web开发中的框架地位，已经从当年的框架绝对王者，变成了如今的框架老旧遗产。2000年代初期，框架Struts 1几乎垄断了Java MVC框架市场。框架那时候面试不问你会不会Struts，框架都不好意思说自己是框架搞Java的。可今天，框架你去问一个刚入行的框架程序员，他可能只在简历上见过这个词。框架 Struts的框架核心思想很简单——把请求分发到Action类，再由Action调用业务逻辑，框架最后跳转到JSP页面。框架这套Model-2架构，框架在当时确实解决了Servlet直接输出HTML的混乱局面。它强制开发者遵循MVC模式，哪怕你不想分，框架也会逼你分。这种“强制规范”在团队协作中特别有价值——我在2008年接手过一个遗留项目，代码乱得像一锅粥，但凡是走Struts流程的模块，结构都还算清晰。 不过，Struts的问题也极其致命。XML配置冗长到令人发指。每写一个Action，你得在struts-config.xml里配一条路径映射，还要配转发页面。一个中型项目，配置文件轻轻松松上千行。改个跳转地址，得在XML里翻半天。更别提ActionForm——为了收集表单数据，你得为每个表单写一个JavaBean，里面全是getter和setter。纯粹是体力活，没有任何技术含量。 Struts 2试图解决这些问题。它借鉴了WebWork的设计，用拦截器取代了繁琐的继承体系，Action变成了简单的POJO。配置也简化了不少，支持注解。但Struts 2有个致命的伤——它继承了WebWork的XWork核心，而XWork的OGNL表达式求值机制，埋下了严重的安全隐患。2017年那波大规模RCE漏洞，让无数企业连夜打补丁。我印象特别深，当时有个客户，系统被扫出十几个Struts高危漏洞，运维团队差点崩溃。从那以后，很多企业直接弃用Struts，转向Spring MVC。 现在回头看，Struts的衰落不是偶然。它太重了，重到和现代轻量级开发的趋势背道而驰。Spring Boot的出现，更是给了它最后一击。Spring Boot用约定大于配置，自动装配，内嵌Tomcat，几分钟就能起一个Web应用。而Struts还停留在“手动配置一切”的年代。这就好比大家都在开自动挡汽车了，你还在教人怎么踩离合换挡。 但Struts并非毫无贡献。它教会了一代Java开发者什么是MVC，什么是分层思想。很多现在用Spring MVC写得飞起的人，早期都是靠Struts入的门。它就像那个教你骑自行车的二八大杠——虽然笨重，但确实让你学会了平衡。 现在还在用Struts的项目，基本都属于历史遗留系统。银行、保险、政府机构这类对稳定性要求极高、升级成本巨大的行业，Struts依然在默默运行。你要是接到这种项目，别急着推倒重来，先摸清业务逻辑再说。Struts的Action类往往承载了太多业务规则，直接重构风险极大。我见过一个跑了十五年的Struts系统，代码烂得跟蜘蛛网似的，但人家业务逻辑就是没错过。这种系统，能不动就别动，让它继续发挥余热吧。 对新人来说，学Struts还有意义吗？我的建议是——不用专门学。但如果你要接手老项目，花半天时间看看它的请求流转流程就够了。真正值得花时间的，是理解它背后的设计理念：如何解耦、如何分层、如何用拦截器做横切关注点。这些思想，放在哪个框架里都不过时。 Struts就像Java Web历史长河里的一块里程碑。它见证了Servlet从简陋到繁荣，也见证了Spring如何一步步蚕食它的领地。技术更迭永远如此——没有谁是不可替代的，只有谁更适应时代的需求。