<svg xmlns="http://www.w3.org/2000/svg" style="display: none;"> <path stroke-linecap="round" d="M5,0 0,2.5 5,5z" id="raphael-marker-block" style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0);"></path> </svg> <p></p> 

官方网站：https://swagger.io/
Swagger 是一个开源的 API 开发和文档框架，Swagger 旨在简化 RESTful API 的设计、开发、测试、文档化和消费过程。Swagger的出现节约了大量的后端人员对接接口的时间，通过Swagger可以快速定义接口文档，方便了前端后端的接口对接工作，废话不多说直接上用例。
这里使用的SpringBoot 是2.6.11 版本

讯享网

启动类增加注解

增加一个接口，方便看到Swagger帮我们生成的接口文档中的接口信息，如下：

讯享网

报错：Failed to start bean ‘documentationPluginsBootstrapper’; nested exception is java.lang.NullPointerException
原因可以参考这篇文章 https://blog.csdn.net/weixin_/article/details/，总结一句话就是SpringBoot2.6以上的版本整合Swagger2:3.0.0会碰到这个问题，根本原因是路径匹配模式不适配。解决方案有两个，他们的目的是为了更改路径匹配规则以适配Swagger2 的3.0 的版本。

• 解决方案一：

• 解决方案二：
  配置文件增加以下配置：

  讯享网

选择上面其中一个方案进行解决即可，然后重新启动就会正常了，如下：

讯享网

到这里swagger的入门集成就成功了，如果你没有设置项目的根路径，那么Swagger的地址就是这个了，如果设置了自行端口后增加根路径就行，打开后如下图：

界面里有四块信息是需要关注的。
左一：展示的信息支持自定义，可以用来标识文档的和服务的信息（第四部分进行详细介绍）
左二：接口展示，这里展示接口的详细信息，最常用的地方,可以看到上面定义的测试接口已经在这里了（第二部分详细介绍）
左三：这里展示我们再请求和响应中定义的实体信息，比如上面接口的UserVO就在这里（第二部分详细介绍）
右一：分组信息，一般用于多个微服务时对不同微服务进行分组，常用与和Gateway集成时对服务进行分组展示（第三部分详细介绍）

这里详细说下Swagger常用的注解，根据使用频率来进行先后说明。这里分为了五个部分来说，前四个部分都是分组来说的，每组注解基本都是一起使用的所以就放一起来说，也方便理解记忆。下面的前四组例子都将使用使用注解和不使用注解的方式来进行说明比对，以此来方便了解注解的具体的作用。

这是使用频率最高的一组注解了。@Api常用与接口类上，用以对当前的接口类做整体声明。@ApiOperation则用于接口方法上，用以描述具体的方法真。

• @Api
  正使用时其实只需要为@Api声明tags标签即可（其他的基本用不到，如果需要再阅读下注解的源码即可），value的值在源码描述中说是当tags不使用时会将其作为资源的描述，但是笔者试了没啥用，而且大家都是使用tags，直接使用tags标签即可。假如存在下面两个方法，他们的信息基本都是相同的，一个使用了@Api注解，一个没有使用：

  下面一起看下他们在Swagger中的展示区别吧（注意重启生效）：
  
  可以看到使用后多了汉字的描述，这样对于文档使用者来说也就更为有好了，这也就是tags属性的作用了，其他属性基本不咋使用。

• @ApiOperation
  这个注解则是使用在接口方法上的，用以描述一个具体的接口，它支持的所有属性都是和RequestMapping对应的，因为他本来就是用来描述接口的和RequestMapping对应则是很好理解的。不过最常用的还是他的value属性，用以简介当前的接口。其他用以描述接口的信息一般不设置也是可以看到的，我们一般使用value属性简单描述接口的作用。
  下面是一组使用@ApiOperation和不使用的代码：

  讯享网

  下面一起看下使用注解和不使用注解在Swagger中的区别：
  

这组注解是使用在实体上的，一般前后端参数交互时都是使用Json数据进行交互，Json交互时后端使用实体和注解@RequestBody来接收前端传递的参数，而这组注解则是用来描述实体的。实体既可以作为接收参数当然也可以作为返回参数。下面一起来看下。

• @ApiModel
  被用于修饰实体类，实体类可用于接口入参和返参，一般只使用value属性即可。假设有如下两个实体信息，一个加了ApiModel一个没有加：

  

  先看下使用了注解时的样子（不使用则显示类名）：
  
  下面是不使用的样子：
  
  此外在下面的位置也是可以看出区别的：
  

• @ApiModelProperty
  这个属性被用在实体的属性上，用来标识实体属性的含义，这个还是很有用的，因为不用他来标识的话有些字段是人无法知道具体代表的含义的。这个也是基本使用value即可，下面也是使用使用和不使用注解来比对下区别，这里就只贴使用注解的代码了

  讯享网

  下面是在swagger文章中看到的区别：
  

上面一组注解被用于标识使用实体接收和返回的数据对象，那么如果接受的数据不是json呢，则需要别的注解来处理了，这一组注解就可以实现这个功能。

• 参数传递大致有以下几种
  • 1.使用body传递json，后端使用注解RequestBody来接收
  • 2.使用body传递form-data，后端使用注解RequestParam接收（文件除外）
  • 3.使用body传递x-www-form-urlencoded，后端使用注解RequestParam接收
  • 4.使用path传参（restful），后端使用注解PathVariable来接收
  • 5.使用query传参，即url传参，后端使用注解RequestParam接收
  • 6.使用Cookie传参，后端使用注解CookieValue接收

上面列举了集中数据的传递方式，可以看到除了Json进行传递，还有一些其他的数据传递，此时@ApiModel这组注解就无法满足我们的需要了，那就只能使用@ApiImplicitParams和@ApiImplicitParam。上面的这些数据传递（除了json）都会在接口方法有参数进行映射。所以使用这组注解就都可以进行声明。这组注解和上面还有一点区别就是必须同时使用。

这里使用query传参进行说明吧。假设有如下接口代码：

不使用注解时，swagger展示如下：

当添加了如下注解以后：

讯享网

swagger中展示如下：

注意：可以看到只是多了在注解ApiImplicitParam中描述的value其他都是相同的，所以说其实使用这组注解时只需要关注ApiImplicitParam他的value就行了。不过需要注意的是这里还是用了注解@RequestParam，swagger文档中的required和query是这个注解赋予的，如果没有这个注解swagger文档是不会有对应提示的。还有一点，若是使用ApiImplicitParam的dataType则一定要使用dataTypeClass不然会一直提示warn日志

上一组注解时用来描述除了实体以外的入参的，这个注解从字面看就知道是跟返回信息有关的，先看下不加这个注解时的接口的返回在swagger中的展示：

然后我们为接口增加这组注解，如下：

下面是使用注解后的swagger文档展示：

可以看到真正有作用的是code和message，所以如果需要使用就使用这两个即可，不过一把不使用这组注解，因为后端服务一般不会抛出http的异常码，而是通过实体的错误码来标识响应信息。

讯享网

因为加了该注解，我们再swagger中是看不到的：

其实不添加任何配置不影响使用，但知道配置方便我们更好地针对自己的特别需求进行定制化。所以配置还是需要进行了解和熟悉的。比如生产上是不推荐打开swagger的，因为有很大的安全隐患。下面一起说下，注意这些配置信息都需要放在配置文件，这里为了方便都直接写死了。

增加完配置信息以后，swagger文档展示如下：

这些配置信息，注意不要直接写死，而应该从配置文件获取，这里直接写死只是为了演示使用，swagger只是项目辅助的小框架就只说到这里了。