2006年，框架我在一个电信计费系统里第一次用Struts2。优点里那会儿团队刚从Struts1迁过来，框架项目经理拍着桌子说“Action里再写request.getParameter就滚蛋”。优点里结果一周后，框架原来需要两百行Servlet搞定的优点里工单查询，被压缩成三十行Action加一个JSP。框架这不是优点里魔法，是框架拦截器栈在背后把参数绑定、类型转换、优点里校验全吞了。框架
Struts2最实在的优点里优点，是框架它把Web层那些脏活累活做成了可插拔的零件。你写个Action类，优点里属性名和表单字段名对上，框架setter一摆，框架自动把字符串转成Integer、Date甚至自定义对象。我见过一个保险理赔系统，理赔单有七十多个字段，用Struts2的ModelDriven接口，Action里只维护一个Claim对象，页面直接写claim.insuredName，连getter都省了。换Spring MVC当然也能做，但Struts2的OGNL表达式在页面取值时更放肆——你可以写#session.user.role == 'admin'，也能在JSP里直接调静态方法，虽然有人骂这太灵活容易埋雷，可赶工期时真能救命。
拦截器是另一个让人又爱又恨的东西。默认的defaultStack里塞了十八个拦截器，从参数过滤到文件上传解析全包了。有次排查一个诡异bug：用户提交的中文参数变成乱码，查了半天发现是params拦截器在action执行前已经把编码定死了。解决方案？在struts.xml里加一行<constant name="struts.i18n.encoding" value="UTF-8"/>。这种“配置即修复”的体验，比在Filter里写chain.doFilter要直观得多。当然，拦截器顺序错了也会翻车——比如你把validation放在params前面，那校验永远拿不到值。
结果类型（Result Type）的丰富程度经常被低估。除了常规的dispatcher转发到JSP，还能用redirectAction直接跳另一个Action，用stream返回文件下载，用json插件把Action属性序列化成JSON。2012年做移动端接口时，后端用Struts2的json结果类型，前端jQuery直接$.getJSON，连Spring MVC的@ResponseBody都不用配。更妙的是<result type="chart">这种自定义结果，当时有个报表项目，把JFreeChart的生成逻辑塞进一个Result里，Action只管返回数据集，图表渲染完全解耦。
标签库虽然长得像JSP自定义标签的远房亲戚，但
值栈（ValueStack）是Struts2的脊椎骨。Action属性、请求参数、会话数据全塞在一个栈里，OGNL从栈顶往下找。这意味着你在JSP里写<s:property value="user.name"/>，如果Action里有个getUser()，它就直接调；如果没有，它会去找#request、#session里的user。这种隐式查找省了无数request.setAttribute，但也让调试变麻烦——有时候你明明改了Action的字段，页面显示的还是旧值，因为栈里某个拦截器压入了同名对象。我的经验是：在Action里加个@Override public String toString()打印栈内容，比看日志快。
文件上传的封装程度值得单独说。Struts2的fileUpload拦截器把multipart请求拆成三个属性：File、String、String。你只要在Action里声明private File upload; private String uploadFileName; private String uploadContentType;，剩下的临时文件清理、大小限制（通过<constant name="struts.multipart.maxSize" value="10485760"/>）全自动。有次客户要求上传2GB的测绘数据，改个常量值就搞定，不用碰Commons FileUpload的API。
当然这框架不是没毛病。配置要么写struts.xml要么用注解，注解多了Action类像贴满便签的冰箱。OGNL表达式注入漏洞在2013年闹得沸沸扬扬，逼得大家升级到2.3.15.1。但如果你维护着十年前的老系统，或者团队里有人对Servlet API犯怵，Struts2的“约定+配置”模式依然能让你少写一半样板代码。至少我见过的政府OA项目里，Struts2+Spring+Hibernate的黄金组合还在跑，Action里注入Service，拦截器管权限，值栈传数据——稳得像台老车床。