一、简单介绍Spring MVC拦截器的相关概念

Spring MVC拦截器3个生命周期方法：

preHandle() ：该方法在控制器方法之前执行，如果返回false,说明拦截器不放行该请求，自己处理或者结束该请求。如果返回true，说明拦截器放行该请求，由其它匹配的拦截器或者控制器继续处理。
postHandle()：该方法在控制器方法调用之后，且解析视图之前执行，可以通过此方法对请求域中的模型和视图做出进一步的修改。
afterCompletion()：该方法会在整个请求完成，即视图渲染结束之后执行。

理解拦截器相关关键字：

匹配请求：如果自定义的拦截器所配置的拦截映射路径与请求中的资源路径符合精确匹配或模糊匹配，则称该拦截器匹配该请求，否则反之。

拦截请求：拦截器匹配请求后，则会进入拦截器preHandle() 方法，不管最终的返回结果如何，只要该拦截器参与了工作，我们都认为该拦截器拦截了该请求，也就是说，至于拦截后放行还是不放行，以具体业务逻辑为主，反正拦截器已参与工作。

不拦截请求：路径匹配失败或者手动指定路径不参与匹配，则不拦截该请求，该拦截器不参与工作(不执行该拦截器的任何方法)。

放行请求：路径匹配成功，并拦截该请求，preHandle()方法处理业务逻辑后，返回true放行，该拦截器已参与工作。

不放行请求：路径匹配成功，并拦截该请求，preHandle()方法处理业务逻辑后，返回fasle不放行，拦截器直接响应请求，该拦截器已参与工作。

放行请求和不放行请求都属于拦截请求后产生的动作，虽然放行请求可以实现不拦截请求的效果，但是需要额外写一些判断逻辑来判断是否放行，建议采用配置拦截器的时候排除路径的方式，从而避免浪费执行拦截器代码的时间。

哪些请求不拦截：已知的，公开性的 如：登录页、静态资源等。
哪些请求要拦截：未知的，需要验证的 如：登录校验、权限校验等。

抛个小问题，为下一篇文章铺垫

相信大家都知道filter过滤器与拦截器的区别，其中一点就是，filter过滤器几乎可以拦截所有请求，而Spring MVC拦截器只能拦截来自控制器的请求。
那么我们可以探讨一个问题，既然Spring MVC拦截器只能拦截来自控制器的请求，为何在访问静态资源的时候，却跑进了自定义拦截器的方法里，这是不是发生了矛盾呢？
其实是这样的，当我们将静态资源的访问交给了Spring MVC来处理的话，那么Spring MVC会将静态资源的请求当成控制器请求，去寻找对应的处理器映射器。如果我们没有配置对应的控制器，也没有使用Spring MVC提供处理静态资源的配置，将会导致访问失败。但是在失败之前，我们的拦截器preHandle()方法已经被执行了。所以从这里可以看出，拦截器之所以可以拦截静态资源，那是因为只要进入Spring MVC的请求。都是对控制器的请求，那拦截器当然可以拦截它了，前提是在拦截路径匹配的基础上，这是毋庸置疑的。

结论：只要是能被DispatcherServlet匹配的请求，都会转变成对控制器的请求，只要拦截器的拦截路径与控制器请求的路径相符合，就可以进行拦截。

以上内容为自己的理解所获，如有误，欢迎留言指正，谢谢！