前言
自动任务执行十分实用————前提是弄懂了执行的优先级，且不会犯低级错误。
任务链
想法
任务链解释起来很简单，无非是一环套一环
实现方式（1）
为了实现自动化执行，一个调用一个的方式看起来很简单，也很符合常理。
但如果单纯只考虑执行，而不考虑执行顺序，我们可以直接采用Spring托管的方式，让Spring帮我们托管要执行的方法————直接在@Configuration注解方法中执行操作也是可行的。
如果要强调先后顺序，可以在@Configuration中规定依赖来判断特定的先后顺序，也可以采用@Order注解来手动判断优先级————不过这样太蠢了。
顺便一提，Spring有时候对于继承自统一父类的多种方法貌似不能很好地进行Bean的托管。
实现方式（2）
如果要更优雅一点，我们可以考虑采用一个register，以及一个依赖于Spring的自动执行方法。
首先声明一个虚拟的父类，以便将它们都放入一个list。
其次实现一个执行器，对任务列表进行顺序执行。一般这种方式适用于在操作前后都需要执行preHandle以及postHandle方法集合的情况。
————需要对被插入操作的方法进行修改。
在初始化时对所有继承自同一父类的不同方法进行注册，并在需要自动化执行时顺序执行即可。这样还可以使不同的方法共享某些资源，减少重复操作。
实现方式（3）
接下来两个方法都和某些非自动执行，而是需要在调用时执行的方法有关。
首先是SpringMVC提供的AOP方法：![SpringMVC的介绍]
————不需要对被插入操作的方法进行修改。
它通过对接口进行拦截，在方法上添加注解@Aspect以及@Component，在进入某些接口附近添加@Pointcut注解，就可以在其附近拿到请求参数了。
// 这里写一下配置拦截的方式
通过拿到的ProceedingJoinPoint对象，我们可以拿到它的参数args[]数组（仅仅依靠类型区分，可能需要遍历来判断）
在执行结束后，我们需要重新回调原接口————直接用ProceedingJoinPoint的proceed()方法就好，你甚至可以把返回参数挂起，再执行之后的操作。
当然，try…finally的后者是必定执行的，即使前面有return操作，大可放心。
这一点可以看这个![finally的执行时机]
实现方式（4）
这种方法是在请求之前执行，获得的数据为整个Http请求。
根据实际的请求参数不同，它实际上可以拿到RequestBody、RequestHeader等，进行一次格式转化即可使用。或者使用RequestContent，不过貌似只能拿到请求头，而非请求体。
————也不需要对被插入操作的方法进行修改。
他也需要在注册时对自己所拦截的接口进行说明，并依赖一条任务链顺序执行。
// 这里写一下配置拦截的方式
顺便一提，在获取HttpServletRequest的数据流后，下一条任务以及接口本身的request就清空了————所以需要手动给request重新赋值，挺蠢的。
// 这里写一下几种流
