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

Question

我在思考是否应该创建一个新的ServeMux并向http.Server注册它，还是直接调用http.HandleFunc和http.Handler？

我认为使用ServeMux路由更好，因为http.HandleFunc显然会干扰HTTP包的全局状态，这在Go中被认为是不好的实践。但是，在许多教程中，甚至是官方教程中，我经常看到使用http.HandleFunc路由的情况。

这让我想知道：为什么有ServeMux时要使用http.HandleFunc呢？我知道ServeMux有一些优点（例如，您可以嵌套它而不必一次又一次地重复前缀），但我想知道为什么我应该选择http.HandleFunc而不是Multiplexer，特别是HandleFunc内部使用了ServeMux。

编辑：如评论中所承诺的那样，我已要求废弃关于Golang-dev上的附加功能（我认为这些功能毫无意义），他们拒绝了（至少有一个人说拒绝了）。 这里是链接。

- Matt3o12

---

我也想说这是一个很好的问题，对于将来的其他人来说也很有用，因为它以前就出现过。 - elithrar

elithrar：这就是我在这里问的原因。我在谷歌上找不到任何东西。在我看来，http.HandleFunc和http.Handle应该被弃用。只需添加两行代码使用Mux和Server，模棱两可总是不好的，特别是如果更明显的方式是“错误的方式”。 - Matt3o12

Go1的兼容性承诺不允许删除，因此我们必须一直使用它们直到“2.0”（这还有很长的时间 - 几年）。 - elithrar

elithrar：我在兼容性承诺中没有找到有关弃用的任何信息。它仍将可用并像现在一样工作（至少在2.0之前），但初学者会远离它。 - Matt3o12

唯一弃用的方法是通过文档注释。Go语言没有“警告”（来自编译器）的概念，因此效果非常有限。欢迎您在golang-dev上提出为这些方法添加文档的建议。 - elithrar

我会的！我认为写一份文档注释会有很大帮助！当我注意到有两种方法时，我做的第一件事就是再次阅读文档。 - Matt3o12

Answer 1

你走在正确的道路上：出于你所列举的原因，你应该优先实例化自己的ServeMux。

使用DefaultServeMux还存在风险，当使用net/http/pprof时可能会暴露剖析端点，因为这些端点会挂载到DefaultServeMux上。

http.Handle|HandleFunc是便利方法，在示例代码中可能有用，以减少样板代码，但创建一个ServeMux可以让你具备包装、嵌套在另一个ServeMux中、从构造函数导出等能力。

- elithrar