struts2拦截器

Struts2的拦截拦截器，说穿了就是拦截一堆Java类，专门在Action执行前后插一脚。拦截你写个登录校验，拦截写个日志记录，拦截写个权限控制，拦截全得靠它。拦截框架自己那些核心功能，拦截比如参数封装、拦截文件上传解析，拦截也是拦截拦截器在干活——只是它们被配置在默认栈里，你平时根本感觉不到。拦截 拦截器的拦截工作方式有点像俄罗斯套娃。你发一个请求，拦截Struts2不会直接蹦到Action里，拦截而是先把这个请求扔给第一个拦截器。这个拦截器做完自己的事，再调用`invoke()`方法，把请求传给下一个。下一个再传下一个，直到最后一个拦截器把请求送进Action。等Action返回一个字符串结果，这个字符串又得原路返回，倒着穿过所有拦截器。每个拦截器都能在请求进来时动手脚，也能在结果返回时再补一刀。 我见过不少新手栽在拦截器顺序上。你配了一个自定义拦截器做参数清洗，结果它排在了`params`拦截器后面——参数早就被框架塞进Action了，你的清洗逻辑对着空对象一顿操作，屁用没有。反过来，你要是把静态参数拦截器放在前面，它设置的属性又会被后面的参数覆盖掉。这玩意儿就像排队打饭，你插队的位置决定了你能不能打到红烧肉。 Struts2的拦截器配置也够折腾人的。你写一个``，它默认会把整个默认拦截器栈都跑一遍，除非你显式声明``。很多人图省事，直接自定义一个拦截器就完事，结果框架自带的那些核心拦截器全被挤掉了——文件上传失灵，参数绑定失效，连基本的ModelDriven都跑不起来。你得手动把`defaultStack`引用回来，再把自己的拦截器插进去。顺序还得仔细斟酌，不然就是给自己埋雷。 我自己的经验是，拦截器适合干横切的事，但别啥都往里塞。你写个业务逻辑，比如“用户下单前检查库存”，这就不该放拦截器里——这属于Action的职责。拦截器该管的是那些与业务无关的琐事：记录这次请求花了多少毫秒，看看用户有没有带合法token，把乱糟糟的输入数据规整一下。判断标准就一条：这个逻辑是不是每个Action都得跑？如果是，拦截器；如果不是，老实待在你自己的方法里。 拦截器还有个坑是线程安全。Struts2的Action是每个请求一个实例，但拦截器是单例的，多个请求共享同一个拦截器对象。你如果在拦截器里放了一个成员变量存请求数据，那高并发下数据就串了。我在一个老项目里见过有人这么干，把用户ID存在拦截器的字段里，结果A用户的操作被B用户顶掉了，排查了整整两天。拦截器里能用局部变量就别用成员变量，能用参数传递就别搞共享状态。 最后说点实在的。Struts2已经老了，现在新项目很少有人用它，Spring MVC的拦截器设计思路也差不多，但更轻巧。你如果还在维护老系统，理解拦截器是必修课——那些诡异的bug，十有八九是拦截器配置顺序或共享状态搞出来的。你要是新学框架，也别跳过这部分，拦截器的思想在Spring、在Shiro、在几乎所有Java Web框架里都是通的。学透一个，到处能用，这笔买卖不亏。