由来：接口文档

古老编程是一个语言前后端通吃，ASP、JSP、PHP都是如此。
但随着项目规模变大，项目团队也开始壮大，岗位职责开始细分，逐渐前端和后端分离成两个岗位，技术栈也逐渐分开。
大前端的兴起这个更加加剧，泾渭分明。

前端目前采用H5、CSS3、JavaScript ES6、Vue3，而后端Java、SpringBoot、SMMP、SpringClould。

这里前端访问后端技术栈的不同，衔接时的矛盾也越来越凸显。
如：后端对应的模块是什么？后端对应的参数、类型、返回值等。
看着很简单啊，开过发的同学就知道，开发时需求老变，链接地址可能变了，参数可能变了，参数类型可能变了，返回值可能变了。这个一变你之前做好的程序那不得统统改了。可因为两个人做，后端改了，没告诉前端，前端不知道，第二天用时怎么错了？查了半天问题，最后发现是后端参数改了。那他不气不发火才怪。

有同学说，不是有接口文档吗？是有，有几个项目的接口文档是能看的？改着改着你就不愿意改了，从而很多接口文档就成了摆设，满篇都是错的。

第一代：Swagger

接口文档是我们的桥梁，后端不能很好维护，这就造成了问题。怎么解决呢？
没有好方法，人是不自觉的，你总不能成天盯着他吧，那更加耗费人力物力。

不知道何时，蹦出来个Swagger，这个东西好。它发明了一套注解@Api @ApiOperation，通过注解，它自动生成API接口文档。

开发人员不是懒得更新文档吗？你总的更新代码吧，那注解就在代码旁边，你总能随手改了吧，而且比改文档，那改的非常少了，如果是代码变动，那都不用改。这极大减少了开发者的工作了，一出来就深受喜爱。

同时，Swagger自动生成的页面就放在项目中，这样后台项目启动，接口文档就可以在浏览器上直接访问，真不要太方便了啊。
还有那，不光如此文档不用写了，Swagger还做了个API测试。
因为我们开发完后端代码时，前端代码可能还没有呢，此时我们想去测试下后端代码的正确性。
Swagger提供了API测试的URL链接，我们还可以配置请求参数，甚至是json格式。 是不是太贴心，太方便了。

但Swagger还是有些页面粗糙，臃肿集成时不方便，又出现了Knife4j。

第二代：Knife4j

Knife4j是为Java MVC框架集成Swagger生成Api文档的增强解决方案

Knife4j的前身是swagger-bootstrap-ui。在swagger-bootstrap-ui的1.8.5~1.9.6版本之间，采用的是后端Java代码和Ui都混合在一个Jar包里面的方式提供给开发者使用。这种方式虽说对于集成swagger来说很方便，只需要引入jar包即可，但是在微服务架构下显得有些臃肿。

取名knife4j是希望她能像一把匕首一样小巧、轻量、并且功能强悍，更名也是希望把她做成一个为Swagger接口文档服务的通用性解决方案。

目前主要支持以Java开发为主,并且是依赖于大环境下使用的Spring MVC、Spring Boot、Spring Cloud框架.
当然,Knife4j也提供了离线版本,只要是符合Swagger的OpenAPI版本的规范JSON,都可以通过简单的配置进行适配，离线版本是适合于任何语言中使用Swagger的,非常的灵活、方便。

界面