2020 年末了,目前的 Golang Go语言 web 框架怎么选?

发布于 1周前 作者 songsunli 来自 Go语言

2020 年末了,目前的 Golang Go语言 web 框架怎么选?

想用 Go 写点东西,看了不少帖子,gin, echo 的名字出现的频率很高,后来发现了 iris,看了框架作者的对比 https://github.com/kataras/iris/issues/1396,觉得也有一定优势。

目前的疑问是,为什么 gin 的热度这么高呢(先发优势+易用性?),iris 是否可以考虑使用,缺陷在哪?


更多关于2020 年末了,目前的 Golang Go语言 web 框架怎么选?的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html

71 回复

gin 吧,简单易用

更多关于2020 年末了,目前的 Golang Go语言 web 框架怎么选?的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html


基于 httprouter 自己撸的一个

上手就选 gin 吧,好用且新手友好。等发现自己的痛点了就知道要比较哪些方面了。

我自己平时都用 beego,虽然老了点,但熟悉

差别都不大,Go 的 web 框架能玩的花样不多,net/http 基础太完善了。

gin 应该有因为 Bilibili 去年意外开源带来的热度。
iris 没用过不清楚。

go 的 web 框架选哪个都差不多。
http 标准库干的事太多了,导致这些框架名字叫框架其实就是薄薄地糊了一层,也没有泛型和复杂的类型推导,基本都是一个人就能维护的工作量,就算凉了自己 fork 一份也不是什么问题。

Go Frame 不行吗, 功能齐全

建议直接标准库…… Golang http 标准库强的很,自己稍微包一层,又快又爽。

应该还是 gin 比较多…

我们就是 net/http 封装一下,然后接一些别的组件就 OK 了,例如日志,队列,redis 、mysql

go 的目标就是简单,就别搞啥框架了 直接梭吧

没有什么是非框架不可的
好好把 net/http 的文档从头看一遍,看看能做什么吧
尤其是那些毫无必要地再封一下的垃圾框架,完全没有存在的必要

gin 的 API 确实好用,可用 chi 封装一下成 gin 的 API

这个时候问,肯定选 zero 啊

Go 和 nodejs 同做 api 服务器的话,哪个更适合?

Go 和 Node.js 速度性能应该是在同一个量级,就看资源库和自己的品味了

在对主机的要求上如何? 2GB 够跑吗?同一台机子上还得再跑个数据库

看你怎么用,测试或自己玩没问题的
1 核 2G 内存的话,1000 个并发访问,QPS 也能达到 2000+
当然搞人工智能,图像识别的另说了

问就是 echo

我也推荐这个,github.com/gofiber/fiber 。它有很多中间件、文档清晰、作者好像是全职维护

刚从 gin 换 echo,gin 的路由冲突就像吃了苍蝇一样难受

另外 gin 没全局异常处理,路由函数不能直接 return err,实在想不通为啥那么多人推荐。

看热度基本是在 Gin 和 Echo 两个间选了

参考 - 最流行的 Go Web 框架: https://www.cyanhall.com/cn/top/go-web-framework/

iris 是基于 fasthttp 的,性能更高,安利一下 fiber,也是,路由比 iris 更好。


这种时候其实应该从自身找找原因,为什么那么多人用 gin ?
搞清楚了可能就进一步了解 go 语言了。

找到了啊,gin 就是不好用

gin 吧,简单性能也好,大厂也用的多

2021 年了,性能真的不是首选目标,用 echo 吧,方便。

自己写,直接用各种自己拼

之前用 Iris,遇到过没有跨大版本,接口变了的情况🙃

比较新,不过貌似最近很多大牛都点赞

服务治理,工具完备,go-zero 可以看看🤩
https://github.com/tal-tech/go-zero

给大家转发下我在 learnku 上写的答案,安利 fiber 的都辣鸡。

自己阅读过 echo gin http.Server 全部、beego 大部分、iris 少量代码,
net/http 体系下 echo > gin > beego > net/http > iris 、goframe 、fiber,下面列出我自己看到的一些不足,不推荐 fasthttp 原因生态相对弱,仅支持 http/1.1 。

echo 中间件闭包消耗大量资源(每一个中间件的成本与其他框架不成比例),router any 方法不具有优先级。单元测试:84%

gin Context 不合理的实现 context.Context 接口(尝试性传递 ctx 会出未知问题),Context 非接口无法扩展,没有内置 Logger 无法自动输出 err (所有 err 必须处理,否在运行出现了 err 自己都不知道),validator 注册不合理( v8 、v9 、v10 可能注册到不同版本里面去了),不支持路由优先级和 any 方法优先级(从 httprouter 继承的问题)。单元测试:98%

beego 程序是单例,代码复杂度过高一个核心方法 200+行( ServeHTTP 方法),内置对象太多导致框架过重无法扩展(内置嵌入了 csrf 、session 等功能但并不需要),体系相对成熟。单元测试:无公开数据

iris 代码抄袭 篡改 git 历史(抄袭 httprouter 被锤改 git 历史 [https://github.com/avelino/awesome-go/pull/1135]( https://github.com/avelino/awesome-go/pull/1135)) 删除老版本代码( git 历史改了一些版本代码没了,老项目无法编译了),httptest 库测试 iris 会 panic,最新版本 api 设计还是不合理,中间件机制少个 for 导致设计极差不合理,HandleDone 方法画蛇添足使用不便,稳定性差每个大版本 api 全变(都 v12 还不合理怎么会稳定)。单元测试:无公开数据 自己单元测试引入 iris 触发 panic

goframe 以前看到的 gmap 组件的软文(18 年),单线程去对比测试 sync.Map ,得出的比 sync.Map 块一倍性能结果 2020 年看还在,这样低级错误严重怀疑水平,大部分代码是工具相关内容。单元测试: 69%

fiber: 低性能 for 循环路由器,没有单元测试,存在 Race Data 导致的 bug 。

关于性能都差不多的没有可以拉开性能差距的地方,随便学一个源码就可以了,结构都差别的没啥难点,看公司需要使用什么。echo 和 gin 加上依赖一共也都有 100 多 M,学那个框架都避不开 net/http 库,这个才是根本。

------------------------------------------------------------------------------------------------------
路由器实现,也都是渣渣。

httprouter 高性能 不支持路由优先级和 any 方法优先级,代码复杂度太高。

chi 中等性能,支持路由优先级,资源消耗是 httprouter 时间 5 倍、内存 10 倍

mux 非高性能路由器实现(没测试,但是实现方法至少慢 20 倍以上,看别人测试数据是比 httprouter 慢 300 倍),使用链式 api 太繁琐与其他库使用方法差距较大同时不具有明显独特优势。

我用得这个 +1

有推荐的吗

我写了顺序级别 就按顺序推荐吧。

看上去 echo gin 二选一?

echo 和 gin 用起来没有太大的差别

echo gin 是差不多,但是我根喜欢 echo,1 、内存 Logger 不需要调用一个方法后收到输出 err,如果有错误内置 err 会自动输出。2 、echo.Context 是一个接口,可以自己去 Warp 定义其他行为 3 、echo 的路由器比 gin 使用的 httprouter 更强,性能差不多在一个级别内,但是 echo 实现了路由优先级。

内置 Logger 不需要在调用一个方法后手动输出 err,如果有错误内置 Logger 会自动输出,debug 时也不会忽略掉错误。例如 session.Store 方法就返回了一个 err,如果有内置 Logger 就会自动打印,debug 时一眼就看出来了。

可以评测下 go-zero🤝

喜欢简单的用 gin 喜欢大而全的用 beego



感觉就是对编程思想理解的差别。
你的几个需求点明显是把其他语言里的惯用思想带了进来。

Go 语言提倡遇到错误就立刻处理它,而不是攒到一起再统一处理。
context 不知道是不是你传进 goroutine 里去了,但也不应该把 ctx 传进业务逻辑代码里。
gin.context 是带扩展功能的,估计你想在 context 添加函数,明显也是从其他语言带进来的习惯。
httprouter 的问题也有很多不错的解决方法。

框架这种东西还是用的人多才是硬道理,当年 Node.js 的 koa 框架都说好,到头来标配还是 express 。
当然真要用的话看个人喜好,但新手还是推荐 gin 。

用 go 搞 web 为什么不用 java .net php

初次玩 Go 可以随便选择一个入门,echo, gin, net/http 都很好,也都差别不大。我玩过这些,现在看大家推荐发现了 fiber, 有点意思,下次就玩 fiber 了。

我好像被降权了,我给你回复你能看见有提醒吗?


1 、context 和 gin.context 不能 go,context 会错误释放,gin.context 这样的都会出并发问题,的这点我清楚,fiber 里面就有这样错误(没单元测试测),context 我会作为业务的 ctx 使用,例如 sql.DB 操作使用 http 创建的 ctx 作为参数使用。
2 、扩展我们可能说的不是一个维度,扩展一是闭包所有框架都可以使用,但是要手动去闭包,扩展二是对象装饰(我好像没有场景);无入侵添加额外函数我自己低性能损耗(框架部分 1%不到)也实现了,另外我没有其他语言的习惯,在使用 go 之前就轻度使用过 django 实现不到 10 个 api 。
3 、httprouter 缺陷没有方法无入侵解决,结构体定义死了,只能重新实现。

微服务玩了不深,没法能力评测 gozero,jaeger 、consul 、prometheus 我也才基本使用,http 我是都看过了也都写过了。

gin 的包装不错,另外就是 echo 强烈安利,至于其他的,我个人就不推荐了。

我看见了,觉得二选一这样简单问题没必要回复你,你自己随意拉都差不多,goweb 这坑又不深,学好 nethttp 就啥都不怕。

非常感谢🙏

你看他机器,内存应该不行,我觉得 go 最好,万一业务成功了,还能拓展

几年前我们写的时候都是用 mux 做路由,后面直接挂官方 http 库的 handler 的,不知道为啥现在都搞得这么复杂

服务治理能力和工程化工具

推荐 gin,通用省事


<br>_ = c.AbortWithError( http.StatusBadRequest, err)<br>return<br>

半年过去了,观点有变化吗?

关注不多
"gin Context 不合理的实现 context.Context 接口(尝试性传递 ctx 会出未知问题" 这个我理解不对,go1.13context 源码优化了实现,我按 10 版本去理解的不对了;在 1.13 之前 context 实现使用的私有类型断言,自己实现 context.Context 接口好像会性能有点影响,异步 go done,记不清了。
goframe 的 sync.Map 的单线程单元测试在 2019.5-2020-5 之间某时间之前就修复了,性能测试和 sync.Map 相同,好像是一个删除 3 倍性能,一个插入 3 倍性能,查询性能完全一样,goframe 的 ghttp 在 web 领域不算顶尖。
fiber 的单元测试还是没有补,单元测试跑完就有的 bug 还是没排。

#23 虽然我写了个方法来处理, 但是还是很蛋疼

又看到这篇帖子,突然发现你分享了那么多,但是没有给出答案,你的推荐是什么呢?

22 年了,有新推荐没?

22 年了,有新推荐没?

23 年了,有新推荐没?

在选择Golang(Go语言)的Web框架时,可以考虑以下几个流行且高性能的选项:

  1. Gin:以其高性能和易用性著称,提供了丰富的功能如中间件支持、JSON验证和路由组织等。Gin使用路由、中间件等技术,能够使得构建Web应用变得快速且简单,是进入Go语言Web框架世界的优秀选择。
  2. Beego:一个全栈的Web开发框架,采用MVC模式,集成了ORM、Cache、Sessions等模块,非常适合API服务和Web应用程序的开发。Beego提供了从前端的页面渲染到后端的逻辑处理等一系列功能。
  3. Echo:高性能且极简的Web框架,专为构建快速的HTTP服务器而设计。拥有良好的路由、错误处理和中间件支持,使得扩展应用功能变得极为方便。
  4. Revel:一个全功能的Web应用框架,无需任何配置即可使用,自带了大量预设好的特性和配置,适用于快速构建Web应用,尤其是大型项目。
  5. Fiber:灵感来源于Express.js的Web框架,结合了Go的高性能与Express的简单性,非常适合有Node.js背景的开发者。

每个框架都有其特点和适用场景,建议根据项目需求、性能要求、社区支持以及开发者经验等因素进行选择。同时,随着技术的不断发展,新的框架和趋势也不断涌现,可以持续关注Go语言的最新动态以获取更多信息。

回到顶部