@Ashe007 可是后端写注解动态生成接口文档，顺便也能帮助前端自动化提效，不考虑侵入式还是很方便的，就是后端麻烦点，可是接口本来就应该写点注释？

@jefferyJQ 区别就是可以随着后端 api 一起预览？

@wssy001 认知里面 star 数侧面能一定程度反应火热程度？

@wssy001 原来是这样，java 是不是有更完美的一体化 swagger api + swagger-ui 方案，不然 knife4j 如果好用，应该这么多年，也不至于才 3K 多 star

@w292614191 knife4j 是注解生成 api + api-ui, 是专门给 java 用的 jar 包，而我这个只是解耦出来的更简单 api-ui 层的抽象🥹，因为我只是个前端 er, 所以能力只够做 ui 层

@smartdoc647 yapi 应该也不好做吧，不然也不会停止维护了？

@smartdoc647 我很认同你的观点，就是做它的原因就是用到 swagger-ui 的地方太难用，想做个稍微人性化点的，其他的却是没有想那么多，国内确实都非常不认同 swagger 这种 api 定义方式

如果你不想用，而你的目标就是更好的控制 loading, react19 提供了一个新的 hook 来同步这种 loading ，叫 useTransition

建议用一下，react-query ，swr 这种支持 promise 异步 http 请求的库，用 useQuery, useMutation 这种 hook, 可以同步请求的 loading 状态，demo 请看：
https://github.com/rookie-luochao/create-vite-app-cli/tree/master/template-react-ts#%E8%B0%83%E7%94%A8%E6%8E%A5%E5%8F%A3react-query-%E6%94%AF%E6%8C%81%E8%87%AA%E5%8A%A8loading%E5%92%8C%E6%8E%A5%E5%8F%A3%E8%AF%B7%E6%B1%82%E8%81%94%E5%8A%A8

轮子造成出来，必须有生态支持，还要推广，还要确实很好用，做一个好工具没有你想的那么简单，我就是做个 api 工具网页 + 包支持 都做不明白

其实轻量脚手架挺好的，但是大家要么用官方的，要么就是直接找个开源项目来 T 代码，而且加上业务沉淀，脚手架感觉是一次性产物，我自己也基于官方的加了点 npm 包自己用，比如我这个项目例子： https://github.com/rookie-luochao/openapi-ui

@azhong123 我不是大佬，这个岗位好像门槛还有点高？半路转行确实不容易，我没有相关经验，无法帮助你，建议你找点相关框架 TensorFlow 、PyTorch 学习一下，再写点东西去投递一下试试

@azhong123 但是楼主说明了背景：需要兼顾做些后端的事了，说明考虑到后端 curd ，所以问 go 的学习

@azhong123 因为前端基础工具很多占有内存和 cpu 的都在用 rust 重构提升效率，学 rust 有机会在这些地方去实践

直接找一个 go 全栈项目，直接变看文档边调试学习

@Shijamlin 一般用 go 还可以写服务端，用 rust 写 web 服务的少，前端更多的是重写基础构建工具，后端主要是重写中间件

@hailaz 还有一点细节是譬如 swaggo 这类 swagger 的代码级实现，生成的是 swagger2 的文档，然后用工具转的 openapi3 ，go 的转换工具转的细节处理的并不是很好，比如 formdata 上传文件的定义转的是有问题的

@hailaz 是你理解的必须带 tag ，我接触过的 swagger.json 定义都是有 tag 的，这让我误以为 tag 字段是必带的，但最重要的原因是我并没有去仔细阅读 swagger 的定义规范

对于技术一般又想写写开源的我来说，写个小工具也被喷了很多，真是感同身受，开源真的很难，也挺佩服那些开源做得好的大佬们，向他们致敬。开源需要包容，你不开源出来，就没办法检验自己，没有人用我们写的东西，我们也就无法知道有没有 bug ，或者哪里需要改进