@OSF2E 先不提 jq，人家定位不同。
React 怎么就第五代了，ng 怎么就第 4 代了？
你的意思是 ng 再发展一段时间就变成 react 了吗？
我觉得如果你好好用过这两个框架就不会有这种结论。

拜托，angular 早好几年就出了仿 react 的状态管理框架了，ngxs 了解下。但是 ng 根本不需要这种状态管理好吗？

你不会觉得 redux 是第六代吧？ redux 就是一坨屎。flutter 的状态管理了解下。


你去想想为什么现在大家都说真香的 Nestjs 仿的是 angular 而不是 react ？细细品。。。

@shuangya 所以说技术选型很重要。

我在说的是，前端技术升级很频繁，但是只要站好队，大部分技术并没有被替代掉。

如果你 5 年前已经开始用 React/Angular 了，到现在他们依然是最火的，不管是向前看还是向钱看。


技术换代的理由绝不是你所谓的 Vue 2.0 刚发布，结果 Vue 3.0 出来了，学不动了，前端好乱。

而是过去一个用 jQuery 1000 行才能写出来的功能，用 React/Angular 200 行就搞定了。
过去用 js 写的大项目，随便修改一个地方就会有 100 个地方出 bug，改成 Typescript 以后系统稳定了很多。
这些才是真正换代的理由。

不要被技术牵着鼻子走，而是要驾驭它们。

其实 egg 在 v2 的时候直接上 ts 可能还有救。

@shuangya 所以说，主流框架还是没变，只是更新了，没有换代。没人逼迫你用最新的。

你看看人家 Angular，整个编译器都重写了一遍，接口兼容性几乎没变。
react hooks 你可用可不用，而且不需要重写，老版本代码就可以一点一点改成 hooks 。
gulp 和 grunt 依然有很多项目在用。
你用框架打包都是人家给你写好的，你根本不需要管什么构建工具。

你觉着 jquery 是不是已经被淘汰了，你可以去 npm 搜搜 jquery 下载量。
Angular.js 1.x 版本，到现在还在维护，谷歌内部也有大量网站基于 1.x 。

对老版本的兼容是开源项目的一种责任和义务。
国内厂家各种技术宣传，然后所有人一拥而上，结果人家毁灭性升级，大家就都懵逼了。
很多公司在技术选型的时候没有做足横向和纵向比较，没有针对自身项目和团队适合度做很好的考量。

@shuangya 正常淘汰？前端主流技术哪个换代了，麻烦科普一下。

感觉可以放弃 egg 了，node_modules 去网上查查怎么工作的，为什么这么多东西。

Nestjs 是正解。

不知道我理解的对不对，感觉楼主有点看不起增删查改呢？

即使相同功能的代码，可读性、可扩展性、可维护性都是千差万别，涉及到各种设计模式、框架理解、语言理解、需求分析等诸多因素。

在一个有严格 code review 的公司里，就算你实现了要求的增删查改，也很容易被驳回并要求修改，提高可读性、提高可维护性、充分考虑需求的变化。

而这些经验，一个应届生是很难有的，但是如果在这种基础上能看到面试者对这些有着一定考虑，那就说明这个人的增删查改比别人的强。

一个 model 应该对应一个表，如果你有多种数据格式返回的需求，应该创建多个不同的 struct 专门用于返回。
可以借鉴 #5 楼给的链接里得各种方法，把不同的返回结构进行拆分、合并、嵌套。

@lancelock 怪心累的，听不懂人话呢，只说最后一次。

看你问这个问题就知道你没怎么用过 go 语言。你以为你是这世界上第一个有这种需求的人吗？
go 语言发展了 10 年为什么找不到你要的所谓的第三方依赖包，因为 go 语言不提倡这么做。

像 #13 楼说的 reflect 其实就是一种动态判断类型的方法，但是，不要这么做，原因自己查。

不要什么后置中间件统一处理，如果你非要这么做可能 go 语言不适合你。


go 语言 json struct 可以嵌套你知道吧？你要做的就是定义好结构体，加好 tag，组合使用他们。
如果这样还看不懂，你也不用回了。

@lancelock 我说得很清楚了，Go 是静态语言，不要想着什么 marshal 之类的优雅解决。
你要做的就是定义一个 response 结构体，把你要返回的数据 mapping 上去。
你可以用一些工具简化这个操作，但是结果都是一样的。

如果你觉得麻烦，不想这样，可以考虑使用 Nodejs 这种动态语言。

@lancelock 原理是一样的，静态语言就是要把 json 绑定到结构体里。不要想着动态解析它，用不来可以用 nodejs，现在 typescript 开发也都要绑定结构体，一样的。

请认真阅读文档：
https://github.com/gin-gonic/gin#model-binding-and-validation

如果遇到路由冲突：
https://hanggi.me/post/golang/wildcard-conflict/

当然好好设计针对 httprouter 的路由规则才是正解。

感觉这几天的更新之后稳定了很多呢。

@zzlettle 你说的这个问题确实存在，但这个其实不是 gin 的问题，而是 httprouter 会产生 wildcard conflict 的问题。
但是并不是说必须要做成你说的那样，你说的那个只是其中一种解决方法，网上搜搜的话能搜到很多解决方案。
https://hanggi.me/post/golang/wildcard-conflict/

httprouter 自己也说，他们就是故意这么做的，要的就是一个性能，如果无法接受可以选择其他不使用 httprouter 的框架。


还有，gin 本身就是一个轻量级、高性能框架。他帮你把 go 语言这类静态语言中很多麻烦的数据绑定、解析、校验的工作都给你做好了，剩下的只要按你的要求添加 gorm, go-jwt, 等库就好了，还要啥。

如果你一定需要一个 full solution 可能确实要自己费点功夫，但也不是你说的自己手撸个什么出来，都是有可以直接拿来用的方案的。

@zzlettle go 做 web 效率低能说出个 1 2 3 吗？很好奇是怎么开发的。
跟 go 直接撸没有区别？你当 github 3 万 stars 都是傻子😓。

不考虑性能是没问题的，但是如果开发效率在差不多的情况下为什么不用强类型，高性能，轻量级，易扩展的 gin 呢？

感觉 go 语言是一个遇强则强，遇弱则弱的语言。
强的可以一 go 到底，弱的就连业余都写不了。

选框架看 stars 说话，国内项目根据情况打折扣。比如：
beego 的星星数：stars/3 就好了，
Vue 的星星数：stars/5 就比较合理了。

Go 只有两个框架 Gin 和 Echo 。别的可以忽略。