在 http 与 mux 上使用 HandleFunc答案

【问题标题】：Using HandleFunc on http vs mux在 http 与 mux 上使用 HandleFunc
【发布时间】：2019-02-13 20:23:17
【问题描述】：

我是新手，想设置一些路由，以及cors。我已经看到了两种这样做的方式，一种使用NewServeMux 初始化多路复用器，然后使用HandleFunc 分配处理程序，另一种直接在http 上使用HandleFunc。这就是我的意思：

mux := http.NewServeMux()
mux.HandleFunc("/api", apiFunc)
mux.HandleFunc("/", indexFunc)

对比

http.HandleFunc("/api", apiFunc)
http.HandleFunc("/", indexFunc)
http.ListenAndServe("127.0.0.1:3001", nil)

这些方法有什么不同吗？如果他们完成类似的事情，是更常见/更实用的事情吗？

【问题讨论】：

使用您自己定义的mux 为您提供更大的灵活性。它将允许您在同一个应用程序中运行多个服务。您不能使用全局mux 来执行此操作，否则在使用相同模式时，不同的服务器实现会重叠甚至可能相互矛盾。

标签： go

【解决方案1】：

http.HandleFunc 等人将您的处理程序应用于ServeMux 的包全局实例，该实例保存在http 包中，http.ListenAndServe 然后启动。您还可以像在第一个示例中所做的那样创建自己的实例，这为您提供了更多控制权并更容易进行单元测试。最后，选择权在你；对于维护期有限的小型项目，便利功能和包全局变量可能很好，但对于较大或寿命较长的项目，我通常建议管理您自己的 ServeMux 和 Server 实例。

【讨论】：

想知道您是否可以考虑使用 DefaultServeMux 作为安全漏洞。您正在托管您可能无法完全控制的路线。是否有“最佳实践”代码验证器可以捕捉到这一点？
@ThomasZeman 我不确定我是否会认为这是一个安全漏洞；你确实可以控制它，因为路由是由编译的代码注册的。没有外部攻击者可以恶意注册路由。
我同意这有点做作，但拉入任意第三方库会增加运行恶意代码的风险，该代码会注册其处理程序。
@ThomasZeman 拉入任意 3rd 方库而不进行审查，无论您是否使用 DefaultServeMux，都存在安全风险。

【解决方案2】：

http.HandleFunc() 使用 DefaultServeMux 这是一个全局变量。因此任何第三方包都可以访问DefaultServeMux。在第三方包被入侵的情况下，它可以使用 DefaultServeMux 将恶意处理程序暴露给您的 Web 应用程序。这就是为什么建议在生产代码中使用您自己的servemux（如您的第一个示例所示）的原因之一。

【讨论】：

是否有任何代码验证器可以发现此类潜在的安全漏洞？