2003年我在一家外包公司做Java Web，技术项目用的技术就是Struts 1.x。那会儿没有Spring Boot，技术没有注解，技术连泛型都还没普及。技术一个登录功能，技术要写ActionForm、技术Action、技术struts-config.xml、技术三个JSP，技术外加validate方法。技术代码量不小，技术但结构清晰得近乎刻板。技术

Struts的技术核心其实就一个东西：ActionServlet。它是技术个HttpServlet，在web.xml里配置成拦截*.do请求。请求进来，ActionServlet根据struts-config.xml里的映射找到对应的Action类。这个XML文件是整个框架的枢纽，节点下每一条都定义了一个URL路径、一个Action类、一个ActionForm、以及若干forward。说白了，Struts干的事就是把HTTP请求的参数搬到Java对象里，再把处理结果映射到某个JSP页面。

ActionForm是个有意思的设计。它本质上是个JavaBean，每个表单字段对应一个属性，提供getter和setter。ActionServlet在调用Action之前，会自动实例化对应的ActionForm，把request里的参数逐个set进去。如果配置了validate="true"，还会先调validate方法做校验。校验失败就回到input指定的页面，错误信息通过ActionErrors对象传递。这套机制在当年算得上优雅，但缺点也明显——每个表单都要写一个Form类，字段多了就是体力活。而且ActionForm是单例的，多个请求共享同一个实例，线程安全问题得自己注意。

Action类的execute方法签名长这样：public ActionForward execute(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response)。四个参数，一个返回值。返回值是ActionForward，代表接下来跳转到哪里。你可以在struts-config.xml里定义全局forward，也可以在action内部用mapping.findForward("success")拿局部forward。这种显式跳转的好处是流程一目了然，坏处是XML配置越来越臃肿。一个中型项目，struts-config.xml动辄上千行，改个跳转得在XML里翻半天。

我印象最深的是Struts的标签库。<html:form>、<html:text>、<logic:iterate>这些标签，配合ActionForm自动回填数据。表单提交失败后，用户之前输入的值不会丢，因为ActionForm还在request作用域里。这个体验在2004年算是加分项。但标签库的语法啰嗦，嵌套深了可读性很差。后来JSTL出来，很多人就慢慢把Struts标签替换掉了。

Struts 1.x的硬伤在于它和Servlet API绑得太死。Action类的execute方法直接依赖HttpServletRequest和HttpServletResponse，单元测试基本没法做。你得启动容器或者用Mock对象，麻烦得很。另外，Action是单例，但ActionForm不是——每个请求都会new一个Form实例。这个设计后来被诟病，因为大表单频繁创建对象对GC有压力。Struts 2换了思路，用Action属性直接接收参数，不再需要Form类，算是进步。但Struts 2的OGNL表达式漏洞后来爆了一堆安全问题，那是后话了。

2006年之后，Spring MVC慢慢起来了。它的方法签名更灵活，不强制继承某个基类，一个@Controller加@RequestMapping就能干活。XML配置也少得多。我最后一次用Struts 1是2008年维护一个老系统，改一个查询条件，得同时动Form、Action、struts-config.xml和JSP。改完之后我心想，这框架确实该退休了。

但Struts的历史地位没法否认。它第一次把MVC模式系统化地带进了Java Web开发，ActionServlet做控制器、ActionForm做模型、JSP做视图，职责划分得清清楚楚。后来的WebWork、Spring MVC、甚至Play框架，多少都借鉴了它的思路。现在回头看，Struts像是一把做工扎实但略显笨重的老工具——效率不高，但你知道它每一步在干什么。