瞎喷
好吧，我们公司现在采用了倒开发模式，先有前端和app再做后台，难道是受了诺兰《信条》的影响吗？要时间钳形作战吗？
如你所见，我这两天已经在搭后台框架了，我就是看着之前的框架太繁琐了，所以从零开始走一个。需要啥用啥，没用的，坚决不要，其他的，用到了再往里边添加。关于自己搭后台框架我也想整理一篇文章，那都是后话了，我真的觉得我应该好好充实一下原理性的东西，很多知识都是知其然不知其所以然，没能闭合成一个环……
切入正题——弱弱的问一句，作为程序员，你们在给前台写接口时，有没有什么痛点呢？
之前写完接口就得整理接口文档，边整边抓狂，好，swagger就是治疗你抓狂的。
说明一点框架结构：spring+mybatis-plus+mysql
我在百度的时候，看了几篇文章，感觉用的方法大差不差，有的是版本不一致的问题，主要是采用两种方式，刚好，这两种方式我都试了一下，整理出来，供有需要的人参考和对比。
第一种方式请看我的上篇文章：springboot整合swagger方式1——com.spring4all/swagger-spring-boot-starter
接下来我们说第二种方式。
1、pom引入
官方文档参考：
battcn/swagger-spring-boot
<dependency><groupId>com.battcn</groupId><artifactId>swagger-spring-boot-starter</artifactId><version>2.1.5-RELEASE</version></dependency>因为官方文档中已经做出说明，因此这里就没有在启动项中添加注解@EnableSwagger2Doc
2、在浏览器输入地址
http://127.0.0.1:8083/swagger-ui.html
我这里设置的项目端口号为8083，输入浏览器即可看到swagger-ui的主页面
可以看到这里与方式1中的swagger-ui主页面明显不一样
3、在接口中的使用
3.1、在类名上使用@Api注解
在swagger-ui页面上的体现：
3.2在方法名上使用@ApiOperation和@ApiParam注解
在swagger-ui页面上的体现：
3.3、在Entity上使用@ApiModel和@ApiModelProperty注解
例如：添加修改操作时我们传递的都是Entity实体类，需要将实体类相关属性根据需要做注解。
在swagger-ui页面上的体现：
至于具体给实体类设置什么样的API文档属性，按需设置即可。
4、接口在线调试
还有一点比较方便的是，支持在线调试
这样操作，真的很方便，为程序员省了很多不必要的付出。你觉得呢？