项目背景

概是在2017年4月份,我们团队整个开发方式都决定使用前后端分离的方式来合作开发,前后端分离当时整个技术方案也是由我来负责整理，探索，如何让整个团队更高效的开发，完成自己的本职工作.从一开始的jsonp，到后面nginx反向代理，这里面我也收获了很多东西，也写了一些相关的博客总结，

但最让人头疼的还是前后端如何针对接口来对接，当时找了很多解决方案，一开始使用的是叫apidocs的，有些类似于写java的注释，使用起来还是不错的，不过没有在线生成的，文档写完后需要单独命令来生成一个文档，挺麻烦，后来就放弃了

最终就考虑使用Swagger来做文档的这块，但Swagger大家都知道，Swagger的ui虽然能把文档说清楚，但是不怎么好用，可能不适合我们国人的眼光吧，至少我是这么认为的，所以当时也就想看看Swagger的生成方式，Knife4j的前身swagger-bootstrap-ui就因此诞生了

这里谈谈swagger，虽然很多人喷他，不好用，基于注解，代码入侵很强，等等 很多原因。但总体来看，swagger发展至今，包括在各个语言，NodeJs、.net、java、php等等，它可以说是一个有些接口规范的东西，从开始，到一步步规范，其实是一个很艰难的过程，任何事物，都不是尽善尽美的，swagger也是一样，至少它给这么多语言提供了一种文档生成的解决方案，其价值就远超它本身的缺点

在Java里面，是Springfox实现了swagger的接口方式(Spring框架几乎统一了Java端Web层框架的实现)，其他语言也类似.

我一直觉得如果前面有人开发出来这个东西，而且用户范围，稳定性都相对较高的情况下，这个东西一定是有他的意义存在的，站在巨人的肩膀上，做正确的事，一直是我认为符合实际情况的,起码你不用自己填坑，因为，做开源，一个想法在当时，可能比较新颖，关注度很高，但是我想，大部分人都逃离不了惰性，缺少的是持之以恒，特别是在中国，很多开源其实都是个人在做（包括目前的Knife4j），意识上，相对国外还是比较薄弱的,而且还有精力，锲而不舍的精神，任重而道远矣~！

但随着项目的发展,仅仅一个swagger-bootstrap-ui皮肤已经不能满足开发者的需求，需要增加更多的服务端代码来满足开发者的需求,所以，作者决定从更名开始，一个新的名字也代表着进入新纪元，Knife4j正式走上了开发者的视野。

所以，Knife4j不仅仅将前身的Ui皮肤通过Vue技术栈进行了重写，也增加了更多个性化的特性增强功能，基于springfox项目以及OpenAPI的规范，希望为Swagger的生态发展做一份贡献。

Knife4j开源至今也有三年半有余了，为自己一直坚持下来打call，也会一直坚持下去，继续维护它，东西虽小,但坚持下去总会有收获.