我应该在 golang 中直接使用 ServeMux 还是 http答案

【问题标题】：Should I use ServeMux or http directly in golang我应该在 golang 中直接使用 ServeMux 还是 http
【发布时间】：2016-07-14 22:07:12
【问题描述】：

我想知道是否应该创建一个新的 ServeMux 并将其注册到 http.Server 还是应该直接调用 http.HandleFunc 和 http.Handler？

我认为使用 ServeMux 的路由更好，因为 http.HandleFunc 显然会混淆 HTTP 包的全局状态，这在 Go 中被认为是不好的做法。但是，在很多教程中，甚至是官方教程中，我经常看到http.HandleFunc路由被使用。

这让我想知道：既然有ServeMux，为什么还要使用http.HandleFunc？我知道 ServeMux 有一些优势（例如，您可以嵌套它而无需一直重复前缀）但我想知道为什么我应该选择 http.HandleFunc 而不是多路复用器，尤其是因为 HandleFunc 在内部使用 ServeMux。

编辑：正如 cmets 中所承诺的那样，我已要求弃用 Golang-dev 上的附加（和无用的 IMO 功能），他们说不（好吧，有人说不）。 Here is the link.

【问题讨论】：

（我也想说这是个好问题，对以后的其他人有用，因为之前已经提出过）
elithrar：这就是我在这里问它的原因。我在谷歌上找不到任何东西。那么，Imo、http.HandleFunc 和 http.Handle 应该被弃用。使用 Mux 和 Server 只会多增加 2 行，而且模棱两可总是不好的，尤其是如果更明显的方法是“坏方法”。
Go1 兼容性承诺不允许删除，所以我们一直“坚持”到“2.0”（这还有很长的路要走 - 几年）。
elithrar：我在兼容性承诺中找不到任何关于弃用的信息。它仍然可用并像现在一样工作（至少在 2.0 之前），但初学者会远离它。
弃用的唯一方法是文档说明。 Go 没有“警告”的概念（来自编译器），因此效果非常小。欢迎您提议在 golang-dev 上为这些方法添加文档。

标签： http go mux

【解决方案1】：

你走在正确的轨道上：你应该更喜欢实例化你自己的ServeMux，因为你已经概述了原因。

在使用net/http/pprof 时，使用DefaultServeMux 也存在暴露分析端点的风险，因为这些端点附加到 DefaultServeMux。

http.Handle|HandleFunc 是方便的方法，可能有助于保留示例代码中的样板，但创建 ServeMux 使您能够包装它、将其嵌套在另一个中、从构造函数中导出等。

【讨论】：