Golang中使用Gorilla/Mux是否不合适？

Golang中使用Gorilla/Mux是否不合适？ 我不想重蹈使用jQuery时的覆辙：投入大量时间学习自认为有用、能让工作更轻松的东西，结果几周辛苦后发现它毫无用处，甚至因拖慢网站速度而产生负面影响。那么，我是否应该使用Gorilla/Mux来处理URL，而不是net/http？这会影响我的网站性能/速度吗？Gorilla/mux能实现的功能，能否用原生的Golang net/http包来完成？

8 回复

该多路复用器的实现基于一个for循环，其性能不如httprouter。

更多关于Golang中使用Gorilla/Mux是否不合适？的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html


/page/:name/:oid 在 httprouter 中，https://github.com/julienschmidt/httprouter#usage。

Mux 比 httprouter 慢 100 多倍，mux 使用 for 循环实现，而 httprouter 使用基数树实现。

好的，谢谢。那么我该如何使用 HTTP 路由器来实现 mux 给我的那种 URL 呢？比如，像 page/{pagename}/{id} 这样的 mux URL 是如何用 HTTP 路由器实现的？

我会从标准库的默认路由器开始，先熟悉使用它， 如果需要更复杂的匹配功能，再转向 gorilla/mux。 两者都稳定可靠、性能出色且被广泛使用。

“Mux 比 httprouter 慢 100 多倍”

这在微秒级别意味着什么？

我坚持我之前的说法，即两者都足够快，并且在实际应用中，与网络和数据库延迟、模板扩展、JSON 序列化等相比，路由器对 HTTP 延迟的贡献微不足道。

而且，与用 Python、Ruby 等编写的框架相比，两者的速度都快得惊人。

我同意路由器消耗的时间比例很小，但在多路复用器性能差距达到100倍之后，它消耗的资源可能与写入日志（logrus、zap）几乎相同。

我查看了其他人的性能测试数据，两者的差异是128倍。例如，chi中其他路由器的性能倍数与我自己的测试结果相同。

GitHub

junelabs/brouter-benchmark

头像

http基础库测试代码，一部分代码来自httprouter的测试代码，一部分代码来自gorouter的测试代码 - junelabs/brouter-benchmark

Gorilla/Mux 是一个成熟的第三方路由库，它不会像 jQuery 那样带来性能负担。以下是关键点：

  1. 性能影响：Gorilla/Mux 在性能上与 net/http 差异极小。它只是对标准库的封装，路由匹配逻辑经过优化，不会成为性能瓶颈。

  2. 功能对比：

    • net/http 提供基础路由：
      http.HandleFunc("/user", func(w http.ResponseWriter, r *http.Request) {
    // 处理逻辑
})
    • Gorilla/Mux 增强功能：
      r := mux.NewRouter()
r.HandleFunc("/user/{id:[0-9]+}", UserHandler).Methods("GET")
r.Queries("filter", "{filter}")

  3. 原生实现限制：net/http 不支持：

    • 路径参数（如 /user/{id}）
    • 路由正则约束
    • 基于 HTTP 方法的路由分组
    • 查询参数验证

    这些功能需要自行实现，代码示例：

    // 手动解析路径参数
func handleUser(w http.ResponseWriter, r *http.Request) {
    segments := strings.Split(r.URL.Path, "/")
    if len(segments) != 3 {
        http.NotFound(w, r)
        return
    }
    id := segments[2]
    // 继续处理...
}

  4. 实际性能数据：基准测试显示 Gorilla/Mux 与标准库性能差距在微秒级，对于大多数 Web 应用可忽略不计。

结论：Gorilla/Mux 不会拖慢网站速度，它提供的路由功能在复杂应用中能减少开发时间。如果只需要简单路由，可直接使用 net/http；但若需要参数化路由、子路由等高级功能，Gorilla/Mux 是合理选择。

回到顶部