前言

最近入职新公司，先临时接手一个认证项目，对于本人这种有代码优雅强迫症的，看到不爽的代码毫无疑问就是改！改！改！然而改完之后前端给我反馈了接口总是报 401 错误。我的内心：我草？难道是我改出 bug 了？不应该吧，这么简单的东西怎么会有 bug ！于是我自己测试了下，还真是有问题，但不是我的问题，下面开始分析！

伪代码场景还原

登录接口，模拟报错

@PostMapping("/user/login")
public LoginResult login(@RequestBody LoginRequest request) {
    throw new RuntimeException("模拟登录接口报错");
}

接着贴出拦截器，如果需要认证的请求没有携带 token ，或者 redis 中查不到该 token 相关用户，就抛出异常

public class UserLoginInterceptor implements HandlerInterceptor {
    @Override
    public boolean preHandle( HttpServletRequest request, HttpServletResponse response, Object handler) {
        String token = request.getHeader("token");
        if (token == null) {
            throw new UnauthorizedException("未认证或token已过期");
        } else {
            if(redis.get(token) == null) {
                throw new UnauthorizedException("未认证或token已过期");
            }
            //...将token和用户信息设置到 ThreadLocal
        }
        return true;
    }
}

拦截器配置

@Configuration
public class WebConfig implements WebMvcConfigurer {
    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(new UserLoginInterceptor())
                .excludePathPatterns("/user/login")
                .addPathPatterns("/**");
    }
}

这个项目是通过拦截器中获取 token 去 Redis 查用户信息放到 ThreadLocal 里面的，由于一个请求从 Controller → Service → Mapper 线程 ID 都是一致的，这样一条请求链都能从这个 ThreadLocal 里面拿到当前登录用户信息。可以看到 /user/login 是被拦截器放行的，然而当这个请求的 Controller 报错，预期的 message 信息应该是模拟登录接口报错，然而运行时报的居然是下面未认证的错，这说明我们的请求走到了拦截器

{
    "path": "/error",
    "message": "com.yinshan.auth.core.exception.UnauthorizedException: 未认证或token已过期",
    "error": "Unauthorized",
    "status": 401,
    "timestamp": "2021-09-22T14:03:39.986559500"
}

当然这个错误信息格式是我自己处理过的，这个不重要，重点是我在登录接口中报 500 的错，为啥变成了拦截器中的 401 未认证。

调试分析

废话少说，直接 debug 走起，在抛异常的代码上打个断点，再把拦截器中打个断点

结果在登录接口按下 F9 之后，断点确实走到了拦截器中，

说实话我当时真的是这个表情，这特么已经被拦截器放行的接口报错关拦截器什么事？然而在调试面板仔细一看 preHandle 这个方法的请求参数详细信息发现了猫腻。

图中箭头指向是很重要的信息：

是当前请求的上下文，正常请求走拦截器时是没有这个上下文
请求的分发类型，正常请求的值是 REQUEST
特别显眼的是这个请求资源 uri，根本不是我请求的 /user/login，而是一个 /error

看到这里大致就明白了，这个断点走到拦截器，不是因为 /user/login 这个请求，而是另一个 /error 请求。那么这个 /error 是怎么来的？由于图中的 TomcatEmbededContext 上下文是 SpringBoot 内嵌的 Tomcat 中的一个类，我猜这个请求应该是 SpringMVC 控制器遇到未处理的报错重新内部发起的一个 /error 请求。

也许你会疑惑，这不是找到问题了吗？好像挺快的呀，你为啥搞了两个小时呢？因为我菜啊！ 我调试的时候压根就没关心这个参数是啥，而是一步一步 F8 → F7 → F8 → F7 ...... 过五关斩六将。。。最后调试到了 DispatchServlet 的时候我才反应过来，这特么怎么跑到请求转发了，最后终于明白了，人都麻了。

查询官方文档

果然在 SpringMVC 的官方文档找到了说明

官网说的很清楚了，如果异常没有被默认的异常处理器处理，那么 Servlet 容器将会用 DispatchServlet 分派一个 /error 请求，也可以对 /error 请求进行定制化处理，详情可以参考 SpringMVC 官方文档

具体原因

SpringMVC 的控制器报错之后服务器会弄一个 /error 的请求，由于我们的拦截器没有放行这个 /error 请求，所以会在 DispatchServlet 中执行该请求的拦截器（我突然想起两年前还写过自定义 SpringBoot 异常页面，就是处理的 /error 请求）

protected void doDispatch(HttpServletRequest request, HttpServletResponse response) throws Exception {
    //...
    //判断并执行拦截器的 preHandle()
    if (!mappedHandler.applyPreHandle(processedRequest, response)) {
       return;
    }

上面是 DispatchServlet 的 doDispatch 部分源码，我相信大多数人对于 doDispatch 的理解都停留在为了面试，背 SpringMVC 执行流程的时候。其实网上对于 SpringMVC 执行流程画的图都是几个关键节点，并没有这么细致，如果说没有真正带着问题调试过这段源码，那么大概率也是不懂这个问题的。

解决方案

明白了问题的原因，解决就很简单了。只要在我们自定义的认证拦截器中排除掉对 /error 的拦截即可

@Override
public void addInterceptors(InterceptorRegistry registry) {
    registry.addInterceptor(new UserLoginInterceptor())
            .excludePathPatterns("/error").addPathPatterns("/**");
}

谈谈拦截器

其实上面的问题很大一部分都是因为对拦截器没有真正的理解，只是知道它能够拦截一个请求，而没有研究过它在什么阶段拦截，在 SpringMVC 中又是怎么去实现的。那么接下来深入分析一下拦截器

拦截器与过滤器的使用范围

查看 Filter 接口源码就能发现，它是 javax.servlet 包下的，而 HandlerInterceptor 是
org.springframework.web.servlet 包下的，拦截器是 SpringMVC 实现的，实际上它只是一个或者多个 Java 类组合实现拦截而已，和 web 应用没有必然联系。这意味着过滤器只能在 web 应用中使用，而拦截器可以用在任何可以用 Spring 和 SpringMVC 的地方，比如桌面应用程序。

拦截器和过滤器的执行顺序&执行流程

过滤器的执行是在请求到达 Servlet 之前通过
ApplicationFilterChain.doFilter() 进行链式调用的，在 doFilter() 内部获取到下一个过滤器实例，执行过滤方法，它的执行顺序是 filter1 → ApplicaitonFilterChain.doFilter() → filter2 → ApplicationFilterChain.doFilter() → filter3 → ......

如下图

而拦截器的执行是请求到达 DispatchServlet 之后针对 Controller 方法执行前、执行后做的一些事情，如下图，这里的过滤器链就是上面那张图

很明显 preHandle() 才是拦截的关键，只有它是在请求到达 Controller 目标方法之前执行的，该方法通过返回 true/false 决定请求是否需要被拦截。

doDispatch 内部对拦截器的处理部分源码

我们都知道 DispatchServlet 的 doDispatch() 方法是处理所有请求的，内部和拦截器相关的代码如下

//调用 Controller 目标方法前执行拦截器的 preHandle()
if (!mappedHandler.applyPreHandle(processedRequest, response)) {
    return;
}
mv = ha.handle(processedRequest, response, mappedHandler.getHandler());//反射调用 Controller 目标方法
/**
 * ...省略
 * */
mappedHandler.applyPostHandle(processedRequest, response, mv);//Controller 目标方法执行完后调用拦截器 postHandle()
//请求完成之后执行拦截器的 afterCompletion()
processDispatchResult(processedRequest, response, mappedHandler, mv, dispatchException);

其实真正带着问题调试过源码的话，根本就不需要背 SpringMVC 的执行流程面试题啦~~~ 我就背不下来，但是从源码调试过程中，我已经很清楚了 DispatchServlet 在请求转发过程中都做了那些事情，结合之前说过的参数校验神器 hibernate-validator 配合统一异常处理自然也明白了 SpringMVC 是怎样实现请求参数的解析、转换的。

结语

遇到问题不要慌，源码调试没有那么难，我觉得带着问题去看源码更能够让印象更深刻。来新公司不到一个月，我已经带着问题看了好几次源码了......正好赶上换技术组件的大版本，总是有各种奇奇怪怪的问题。

平时多看看框架、技术组件的官方文档真的是一个非常好的习惯，不要总局限于某些视频教程。多读官方文档，才能发现组件可能存在的问题，出现问题的原因。

电脑装配网

一个 /error 引发两小时的 SpringMVC 源码 debug

人阅读 | 作者小编 | 时间：2021-10-09 19:50

前言