2020 年末了，目前的 Go web 框架怎么选？

gin 吧，简单易用

基于 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 的文档从头看一遍，看看能做什么吧
尤其是那些毫无必要地再封一下的垃圾框架，完全没有存在的必要

iris 的问题是有黑历史 https://github.com/avelio/awesome-go/pull/1135

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

这个时候问，肯定选 zero 啊

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

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

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

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

问就是 echo

@cryingsky 我也推荐这个，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 更好。

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

@Hanggi 找到了啊，gin 就是不好用

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

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

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

aah

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

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

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

goFrame

@sunmoon1983 #36 +1

给大家转发下我在 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 太繁琐与其他库使用方法差距较大同时不具有明显独特优势。

@cryingsky 我用得这个 +1

@eudore 有推荐的吗

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

@eudore 看上去 echo gin 二选一？

buffalo

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

@jmyz0455 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 时一眼就看出来了。

@eudore 可以评测下 go-zero

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

@eudore

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

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 了。

@eudore 我好像被降权了，我给你回复你能看见有提醒吗？

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

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

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

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

@eudore 非常感谢

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

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

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

推荐 gin,通用省事

@FreeEx
```
_ = c.AbortWithError( http.StatusBadRequest, err)
return
```

@eudore 半年过去了，观点有变化吗？

@vincentxue 关注不多
"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 还是没排。

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

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

22 年了，有新推荐没？

22 年了，有新推荐没？

23 年了，有新推荐没？

chi