「这是我参与2022首次更文挑战的第11天，活动详情查看：2022首次更文挑战」。
哈喽大家好，我是阿Q！
上文我们讲到了springmvc对@RequestBody注解的依赖，本文我们将仔细分析swagger对@Requestbody的依赖问题！
swagger对@Requestbody的依赖
经过调用栈追踪，最终发现在两个地方的功能会对@RequestBody注解有单独判定！（感兴趣的可以自行追踪😃）
- 请求类型判定：也就是说
POST请求类型是哪种类型，这决定了入参是否会作为Request Parameter被展开参数，也就是文中的第一张图，整个model都被视为ModelAttribute展开了。 Definition属性值填充：这确保被@RequestBody注解修饰的入参会被正常显示，如文中第二张图片所示。
请求类型判定
源代码位置：https://github.com/springfox/springfox/blob/2.9.2/springfox-spring-web/src/main/java/springfox/documentation/spring/web/readers/operation/OperationParameterReader.java#L151
这里对RequestBody等常用注解进行了单独的判定，确保这些注解修饰的入参不会被作为RequestParam展开。
Definition属性值填充
Definition属性中填充了入参、出参等参数类型，如果没有相应的Model定义，则swagger信息就会是不完整的，在浏览器页面中的显示也会是不全的。填充Definition的逻辑也依赖于@RequestBody注解。
源代码位置：https://github.com/springfox/springfox/blob/2.9.2/springfox-spring-web/src/main/java/springfox/documentation/spring/web/readers/operation/OperationModelsProvider.java#L80
可以看到，只有被RequestBody注解和RequestPart注解修饰的入参才会被接收进入Definition属性。
综合以上两张图的源代码分析，可以看到，swagger功能依赖于@RequestBody注解，入参如果不被该注解修饰，则swagger功能就会不完整，这和在springmvc中使用独立的参数解析器功能不得使用@RequestBody注解矛盾。
既然大家都知道了问题所在，那么我们接下来的任务就是围绕解决问题来展开了。下文我们将给出具体的解决方案！
题外篇
阿Q将持续更新
java实战方面的文章，感兴趣的可以关注下公众号：阿Q说代码，也可以来技术群讨论问题呦,点赞之交值得深交！
