「这是我参与2022首次更文挑战的第10天，活动详情查看：2022首次更文挑战」。
哈喽大家好，我是阿Q！
前情提要
看了上一篇文章的小伙伴，应该已经对使用参数解析器来完成第三方接口的统一验签有了清晰的认识。
我们在上文中提到过，@RequestBody使用的参数解析器RequestResponseBodyMethodProcessor优先级高于我们自定义的参数解析器，所以为了正常使用，需要将@RequestBody 注解去掉。这就会导致swagger无法识别正确的参数类型，将请求体识别为Query Params，然后将body展开。
可以看到，所有参数都被识别为ModelAttribute类型（query标志），而我们所期待的正确格式应当是如下样子
因为该方式可以大大提高代码的可读性和可复用性，所以我们要知难而上，找出问题，解决问题！
问题产生的原因
产生这个问题的根本原因就是spring mvc和swagger都对@RequestBody注解进行了单独的判定，功能上都依赖于该注解本身。
springmvc对@RequestBody注解的依赖
就拿当前自定义的参数解析器来说，如果对请求参数加上了 @RequestBody 注解，对参数的反序列化会提前被RequestResponseBodyMethodProcessor拦截，自定义的参数解析器会失效。
具体源代码位置：https://github.com/spring-projects/spring-framework/blob/5.2.x/spring-webmvc/src/main/java/org/springframework/web/servlet/mvc/method/annotation/RequestResponseBodyMethodProcessor.java#L111
可以看到，该参数解析器对加上@ReuqestBody注解的参数都支持解析，然后做序列化的操作。然而它在参数解析器列表中的优先级比较高，自定义的参数解析器添加到参数解析器列表之后会排在它的后面，所以如果加上@RequestBody注解，自定义的参数解析器就失效了。
因此使用自定义参数解析器一定不能使用@RequestBody注解
下图源代码位置：https://github.com/spring-projects/spring-framework/blob/5.2.x/spring-web/src/main/java/org/springframework/web/method/support/HandlerMethodArgumentResolverComposite.java#L129
此案例中用到的自定义参数解析器为
HdxArgumentResolver
看了springmvc对@RequestBody注解的依赖后，下文我们将仔细分析swagger对@Requestbody的依赖问题！
题外篇
阿Q将持续更新
java实战方面的文章，感兴趣的可以关注下公众号：阿Q说代码，也可以来技术群讨论问题,点赞之交值得深交！
