Golang Gorilla Toolkit 已进入归档模式
Golang Gorilla Toolkit 已进入归档模式 我不确定这里是否已经发布过,所以我想我应该发一下。自2022年12月9日起,整个Gorilla工具包已进入归档模式:
Gorilla Web Toolkit
Gorilla是一个用于Go编程语言的Web工具包,为编写基于HTTP的应用程序提供了有用的、可组合的包。- Gorilla Web Toolkit
这个Reddit帖子有很多很好的讨论:
![]()
r/golang - Gorilla Web Toolkit is now in archive only mode
目前Reddit上有244票和90条评论。
我很想听听你们对此的看法,特别是关于它如何影响使用Gorilla工具包的项目。我可能不会再继续使用gorilla/websocket了(不过说真的,现在有什么替代方案呢?),因为它可能随着时间的推移需要改变。然而,我有几个项目在使用gorilla/mux,我不确定在可预见的未来是否会将它们迁移到其他东西上。我的意思是——一个HTTP路由器真的需要经常改变吗?
对于新项目,如果你熟悉它,继续使用gorilla/mux可能仍然是安全的。它被很多项目使用,我不得不想象有人会去分叉/维护它。对于我大多数新的API,我倾向于使用julienschmidt/httprouter(或者标准库)。但我很好奇论坛上的其他人正在做什么。
更多关于Golang Gorilla Toolkit 已进入归档模式的实战教程也可以访问 https://www.itying.com/category-94-b0.html
但我想知道论坛上的其他人是怎么做的。
作为一名新手,我发现内置的 ServeMux 足以满足我的需求。而且我发现无论是对于网站还是 API,它都更简单、更灵活。我测试过 gorilla 和 fasthttp,但我觉得对于一个刚接触 Go 语言的人来说,它们的逻辑是反过来的。我从未让它们工作起来……
更多关于Golang Gorilla Toolkit 已进入归档模式的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html
我还没用过Chi,但我注意到它非常活跃,似乎很多人都在新项目中使用它。下次我启动新API时可能会试试看。
是的——在官方的websocket仓库中,我注意到他们移除了指向gorilla/websocket的链接。现在他们推荐nhooyr.io/websocket,这个项目虽然不是特别活跃,但至少有一些活动。根据README:
注意:我没有及时回复问题跟踪器上的问题/报告,但我确实会阅读,并且目前没有未解决的错误。当然有一些锦上添花的功能我应该合并进来/弄清楚,但没有什么是关键的。我并没有放弃添加新功能和进一步清理代码,只是最近比较忙。如果出现任何关键问题,我会修复它。
我猜这是目前最好的选择。不过我从未使用过它,而gorilla/websocket用起来相当简单/符合人体工程学。
Gorilla工具包进入归档模式确实对现有项目有影响,但不必过度担忧。以下是具体分析和替代方案:
1. 对现有项目的影响
gorilla/mux:功能稳定,API成熟,短期内无需迁移。示例:
// 现有代码可继续使用
router := mux.NewRouter()
router.HandleFunc("/api/{id}", handler).Methods("GET")
gorilla/websocket:需评估长期维护风险,建议逐步迁移。
2. 替代方案
- 路由器:标准库
http.ServeMux(Go 1.22+支持模式匹配)或julienschmidt/httprouter
// 标准库示例(Go 1.22+)
mux := http.NewServeMux()
mux.HandleFunc("GET /api/{id}", handler)
- WebSocket:官方
golang.org/x/net/websocket或nhooyr.io/websocket
// nhooyr.io/websocket示例
import "nhooyr.io/websocket"
conn, err := websocket.Accept(w, r, nil)
3. 迁移策略
- 新项目直接使用替代方案
- 旧项目:监控依赖安全,逐步替换非核心功能
- 关键项目可考虑维护分支
4. 社区动态
已有多个活跃分支出现,如gorilla/mux的社区维护版本。可通过GitHub搜索"gorilla fork"找到近期更新的分支。
归档模式意味着官方不再更新,但经过十年发展的稳定代码库仍可安全使用。重点监控安全漏洞,制定长期迁移计划即可。


