当初跟着老项目改代码的时候，被前辈冷不丁问起struts2是什么，我支支吾吾说不全，只晓得项目里面一堆xml配置文件，改一个跳转路径就要翻半天配置，那会才意识到自己对这个东西的认知一直停留在表面。

那阵子接手的是一套年头很久的后台管理系统，底层就是用它搭起来的，平时写业务，不用自己去写接收请求、封装参数那一堆重复代码，请求过来之后，框架会自动把前端传过来的参数绑定到Java类的属性上，再调用对应的业务方法，处理完再根据配置跳转到页面或者返回别的资源。这只是我的个人感受，不是标准答案。

很多刚接触Javaweb的人，会把它和SpringMVC放在一块对比，我身边一起学的同学就是这样，他上手SpringMVC之后，觉得注解写起来省事，回头看struts2一大堆xml，直接不想碰。他说这种靠配置驱动的方式，维护起来费劲，小改动都要找对配置节点，稍微写错标签，启动直接报错，日志还不好定位问题。

我倒是慢慢摸出一点它的运转路子。它核心是一套拦截器栈，所有进来的请求，会挨个经过预设好的拦截器，参数解析、校验、异常处理这些功能，都拆分在不同拦截器里面，不想用哪个，或者想加自己的逻辑，调整拦截器配置就行，不用改动业务代码。只是这套机制理解门槛摆在那，刚上手的时候很容易搞混值栈、OGNL表达式这些配套的东西，页面取值的时候经常拿不到数据，对着页面代码反复调试很久。

它属于MVC模式的框架，把请求、业务、视图拆开。控制器不再是一个个单独写的Servlet，换成Action来承担，一个Action可以写多个处理方法，对应不同的业务动作，不用新建很多Servlet类。很多老系统选择它，也是早些年这类框架选择不多，它把很多通用web能力封装好了，不用从零手写Servlet。

后面慢慢发现，新项目很少再选用它了，大部分团队转向别的轻量化框架。不是说它本身没法跑，而是配置模式和现在大家偏好注解开发的习惯不太契合，加上配套的生态更新节奏慢下来，新人学它大多只是为了维护遗留老工程，很少拿它从零搭建新的业务。

我到现在也没有深挖它全部底层源码，只停留在够用就行的程度，能看懂现有配置，修改跳转、简单参数接收，保证老系统正常迭代。遇到复杂的自定义拦截逻辑，我一般也不会在原有基础上大肆改动，尽量顺着原有写法去调整，避免牵一发而动全身，引出一堆意料之外的问题。

翻旧项目配置文件的时候，还会偶尔想起当初答不上问题的窘迫，它就是一段旧技术周期里，被大量项目选用的Javaweb框架，见过它的人，大多都是在维护存量系统的时候和它打交道。