最近在写一个Springboot项目时，需要接入Swagger功能，过程中遇到了几个问题，其中就数@requestBody不兼容Swagger的情况最难受，其他还有遇到问题，这里整理一下，分享一下解决方案。这里希望把Swagger当做一个接口文档展示和接口调试的工具，而且支持测试环境和上线后的环境。
@requestBody兼容性问题
关于这个问题网上搜到的两个方案排名靠前：
- 通过环境配置，分开线上和线下环境，避开这个兼容性问题
- 通过修改参数解析器解决
这里复制一下大神的分析结论：
根本问题是springmvc中独立的参数解析器功能和swagger功能上的冲突，一个要求不能加上@RequestBody注解，一个要求必须加上@RequestBody注解。 从springmvc入手，想办法提高自定义参数解析器的优先级，只要自定义的参数解析器优先级比RequestResponseBodyMethodProcessor高，则就可以在自定义的参数上加上@RequestBody注解，swagger功能自然而然就能正常了。 从Swagger入手，想办法解决掉上面两部分对@RequestBody的单独判定，不修改springmvc相关功能也可以让swagger功能正常。 考虑到修改springmvc功能可能会对以后的版本升级造成较大影响，这里决定利用切面修改原有的swagger对@RequestBody的两个地方的行为。
但是这两个方案对我来讲的确略微复杂了，总的来说不好抄，就是抄完代码发现很多注解和import没有对应的依赖，自动搜索添加后又面临一些版本兼容的问题，所以暂时放弃了。
Swagger API请求超时
这个问题存在Swagger 2 和Swagger 3版本，一开始我在Swagger 3上遇到了，但是很奇怪我切换回Swagger 2就解决了。当时怀疑是Swagger 3和Groovy的兼容性问题。没太注意，后面被迫切换到Swagger 3（也是判断失误导致的），逼得不得不解决这个问题。
经过查询stackoverflow网站，原因是groovy.lang.MetaClass的问题，Groovy所有类都继承groovy.lang.MetaClass，数据量非常大，导致生成Swagger JSON文件的过程中耗时非常多，我本地运行使用了30 s左右。
一键解决
方案依然来源于stackoverflow，就是在Swagger配置中把groovy.lang.MetaClass过滤掉即可。虽然这个方案是为了解决生成Swagger JSON耗时较长的问题，但是经过测试发现顺带的把@requestBody的兼容性问题也一起解决了。这真是意外之喜。