个人开源需要有比较独特的东西才可能成功。我的 smart-doc 就是个人项目，目前来看在国内的使用情况还可以。也有大厂参照思路内部造轮子的，但是他们都没开源。主要是做的造，社区都知道最初的设计思路从哪里来的，可能也是大厂参考后不开源的原因

@lyxeno thank you

小公司没有严格的安全检查，大公司早就被安全部门找到你了，大厂一般点的情况先警告，严重的直接全公司通报，然后开除，领导也受会牵连。产品的核心其实好的交互设计，代码其实不重要，带走没什么意义，知道交互设计找个好的程序员就可以复制出好产品了。

gradle 的问题主要是版本兼容性不行，对于业务项目搞都后面就项目多了就没人想动了，升级改配置麻烦，我做构建平台的就要给业务提供几个版本的 gradle 环境，maven 我只提供一个给业务目前都没发现问题。我开发 gradle 插件也是也有类似问题，兼容性不行，大版本升级就重新适配，不知道 gradle 7 以后的版本升级能不能兼容性好点

@v2orz 有问题可以提 issue 的，附带导致错误的用例就可以，毕竟要面向很多写法。都是不断迭代修复

@v2orz 自定义注解肯定不属于我的支持的范畴，注解属性就很宽泛，都是有一定框架使用范围的。开源一般只做一些标准框架支持

smart-doc+torna，目前开源产品中国内最成熟的，科大讯飞和顺丰这些公司都在用，不是吹出来的。

yapi 国内有替代品，国内基于 java 开源的 torna 基本已经覆盖了 yapi 的功能，java 开发的同学配上 smart-doc 基本都不用自己写文档。https://gitee.com/durcframework/torna

spring 技术栈 smart-doc+torna 才是王道

@chendy 重新搞东西都是很难的，需要耗费很多精力，smart-doc 开发的过程中也经历过很艰难的时候想放弃，但是后来因为得到很多开发者的喜爱和一些大公司的引入才有了维护下去的动力。关于是以代码先行还是设计先行，这和 smart-doc 这种工具本身不冲突，我们团队很多项目也是设计先行，但是根据设计写好代码后可以通过工具扫描代码生成接口文档，比如 openapi 的文档数据，然后可以把这种文档直接发送到集中化的文档管理系统中，这对于大型微服务文档集中化管理还是提供了很多遍历的。

@hantsy 首先非常欣赏你丰富的研发经验。第二种方式本身和这个工具不存在冲突，当然实际落地也很难。
smart-doc 开源的初衷也不是奔着造轮子去的，在使用 smart-doc 之前我也使用过你提到的这些工具，可能是我经验欠缺吧没有用好它们，反正就是对这些工具够不满意，然后重新开发了这个工具。后来在不断的开源迭代中，发现得到国内很多开发者的支持，在这个发展过程中，我们也一直关注国内外相关的工具、也非常重视像 OpenAPI 3.0 这样的行业标准。因此我们也做大量的支持和测试。

注意看文档，一个单元测试仅仅用于启动 smart-doc 扫描代码，smart-doc 和 swagger、Spring Rest Doc 都不是一个原理，smart-doc 完全基于定义好的接口源码和注释分析生成文档。我一直的原则是，如果重复造轮子又不能比现有工具好没有意义。

smart-doc 支持生成静态 html、markdown、adoc 甚至是 postman 上测试的接口 json 文件，生成的 html 页面干净整理开用和 Spring 官方文档一样的模板样式，markdown 我们有很多用户稍微修改下就能转成 pdf 作为和外部公司的对接文档。postman 的 json 文件可以一键导入。码云上的 wiki 都有详细介绍。

smart-doc 是强制要求写注释的，上百家企业选择不是自己吹的，没有好的点就成烂尾项目了

觉得其他工具复杂的可以试下 smart-doc，完全不用不写注解。虽然没有名气，但是针对 springboot 技术栈的接口扫描生成文档来说是很智能的。