前几天同事使用POSTMAN做接口测试时遇到一个问题，前端传值后台报了404错误，当时他看到错误觉得很奇怪和自身的 controller层返回的数据结构不一样，其实根本没有进入到方法体里就能解释为什么不是自己的返回结构。

以前也经常遇到这个错误，也没有特别的关注这事，不关注的主要点是spring mvc返回的结构与我们的结构定义基本一致，前端解析时所以没有什么影响，但是目前公司采用的数据结构不一样。看图

解析成功图

说下404错误的三个大致原因，1：找不到对的请求路径，2：请求方式错误，3、请求参数错误。根据message提示就更好的看到具体的原因了，下面使用了一个枚举类，没有匹配到就报错了。

解析失败图

枚举值

产生这个异常原因是参数输入了不存在相应的值，同事的本意想没有匹配到的情况下，上报前端 msg="xxx not found"的业务异常，于是在枚举里做一些处理：

处理后

这里报出异常是做了一个统一处理的异常机制,使用@ ControllerAdvice注解统一，针对HttpMessageNotReadableexception异常了做了回应，得到我们想到返回结构体。

异常处理图

接下来就是再次测试时，断点时找到不同的地方是，这个统一处理异常的方法被调用了，想想这个问题应该可以解决了，但是发现结果还是和上面的解析失败的结果一样的，为什么还是返回 spring里的错误结果404？这里需要就需要去了解 spring-mvc的工作原理，找到是哪个地方返回的结果。

先来看看 spring-mvc的工作原理图，再去找找原码分析下

转发百度图

根据上面图流程找到调用相应的 controller的处理逻辑处，看看是怎么又调用了 spring的controller处理器。

分发器

上图的红框中根据请求的 request对象获取相对应的mappedHandler，再跟 handler查找出适配器 RequestMappingHandlerAdapter

调用具体方法

调用方法后，调用请求再解析参数如图：

调用请求

解析参数

具体报错位置

其实报错位置直接可以看日志就可以找到，找到错误就可以找向上找到返回的异常对象，再调用了全局异常处理的地方

全局异常处理

全局异常处理完后并没有直接返回我们想要的结果，而是进一步进行处理，继续往下看：

返回值

下图就是处理分发的结果值，调用了 render方法向前端渲染，这里是真正的返回结果处。

渲染

渲染逻辑

response.isCommited is false，框中的进行 forward跳转，结果并没有返回。同样的请求 FrameworkServlet再次调 doservice的时候 uri前加了控制器的请求前缀，所以又找不到了404了， 发现 reques请求错误时，又再次调用了 doService方法请求到默认的 BasicErrorController,一次请求执行了三次，最终的结果被覆盖了，于是就出现 spring的返回结果，这终归是spring mvc处理接口这类错误的一致处理方法吧。

最后讲讲解决问题的方案：

1、可以实现BasicErrorController的方法来覆盖（不可取，有点异类）

2、调整自身的返回结果体（不可取，项目刚开始可以改，影响大）

3、不使用枚举类做映射

4、调整自身枚举类解析方法，不用异常，进入方法体做业务校验，返回NULL即可

解决方案

如果本文对你有帮助，别忘记给我个3连 ，点赞，转发，评论，

，咱们下期见！答案获取方式：已赞 已评 已关~

学习更多JAVA知识与技巧，关注与私信博主（666）