何为http.ServeMux？
http.ServeMux是什么？官方定义为http服务的多路复用器。可以让开发在http服务器中自定义不同的path路由和对应的处理函数，我们简单举个例子：
package main
import (
"net/http"
"fmt"
)
func HandleABCFunc(w http.ResponseWriter, r *http.Request) {
fmt.Fprintf(w, "%s %s\n", r.Method, r.URL)
}
func main() {
http.HandleFunc("/abc/", HandleABCFunc)
http.ListenAndServe(":8080", nil)
}
Where is the http.ServeMux? Are you kidding me? 别急，我们打开看看http.HandleFunc源码
// DefaultServeMux is the default ServeMux used by Serve.
var DefaultServeMux = &defaultServeMux
var defaultServeMux ServeMux
...
// HandleFunc registers the handler function for the given pattern
// in the DefaultServeMux.
// The documentation for ServeMux explains how patterns are matched.
func HandleFunc(pattern string, handler func(ResponseWriter, *Request)) {
DefaultServeMux.HandleFunc(pattern, handler)
}
原来go为了减少开发的重复性，简单的封装了一个默认的http.ServeMux，也就是说通过http.HandleFunc注册的处理函数，统一由默认的http.ServeMux来解析和调用，如果你想定制http.ServeMux来处理自己的业务逻辑，那就需要修改上述例子：
func main() {
mux := http.NewServeMux()
mux.HandleFunc("/abc/", HandleABCFunc)
// ...
http.ListenAndServe(":8080", mux)
}
它有什么坑？
OK！既然知道什么是http.ServeMux，我这里说下最近使用它遇到的一个问题，我们以上面/abc/为例子描述这个问题。
首先，把代码保存到server.go，直接使用go命令跑起来。
go run server.go
然后，我们再编写一个客户端client.go，打印服务端的返回body体信息；接着与server.go一样，直接使用go命令跑起来。
package main
import (
"net/http"
"io/ioutil"
"fmt"
)
func main() {
resp, _ := http.Post("http://127.0.0.1:8080/abc", "", nil)
if resp != nil {
body, _ := ioutil.ReadAll(resp.Body)
fmt.Println(string(body))
resp.Body.Close()
}
}
结果！我惊讶了！
go run client.go
# GET /abc/
我明明是POST请求，怎么服务端收到的是GET？难道我命中坑位？
似是而非
习惯性地，我用cURL请求调试一把服务端，发现了些端倪。
curl -vL -XPOST http://127.0.0.1:8080/abc
* Trying 127.0.0.1...
* Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0)
> POST /abc HTTP/1.1
> Host: 127.0.0.1:8080
> User-Agent: curl/7.47.0
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Location: /abc/
< Date: Mon, 12 Nov 2018 02:49:30 GMT
< Content-Length: 0
< Content-Type: text/plain; charset=utf-8
<
* Connection #0 to host 127.0.0.1 left intact
* Issue another request to this URL: 'http://127.0.0.1:8080/abc/'
* Found bundle for host 127.0.0.1: 0x55b8d54ce0c0 [can pipeline]
* Re-using existing connection! (#0) with host 127.0.0.1
* Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0)
> POST /abc/ HTTP/1.1
> Host: 127.0.0.1:8080
> User-Agent: curl/7.47.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Mon, 12 Nov 2018 02:49:30 GMT
< Content-Length: 11
< Content-Type: text/plain; charset=utf-8
<
POST /abc/
* Connection #0 to host 127.0.0.1 left intact
如果直接看结果，cURL是预期的结果，还真以为是go的BUG，但仔细看了下请求过程，发现中间多了一次重定向请求，这就有点奇怪了？为什么go服务端会返回301 Moved Permanently？只好翻翻官网资料。
https://golang.org/pkg/net/http/#ServeMux
If a subtree has been registered and a request is received naming the subtree root without its
trailing slash, ServeMux redirects that request to the subtree root (adding the trailing slash).
This behavior can be overridden with a separate registration for the path without the trailing
slash. For example, registering "/images/" causes ServeMux to redirect a request for "/images"
to "/images/", unless "/images" has been registered separately.
对比上述例子，我请求的是/abc会被重定向为/abc/，处理方式就是返回客户端让其自己重定向请求到/abc/，听起来很合理，但go客户端为什么修改了我的请求method呢？难道是go标准库http.Client的BUG？再找找资料。
https://tools.ietf.org/html/rfc7231#section-6.4.2
Note: For historical reasons, a user agent MAY change the request
method from POST to GET for the subsequent request. If this
behavior is undesired, the 307 (Temporary Redirect) status code
can be used instead.
真相大白！RFC7231中对301 Moved Permanently有一段额外说明，就是历史原因，客户端可能会将POST请求重定向为GET，为此如果真想不修改方法进行重定向，在HTTTP/1.1里面新定义了307 Temporary Redirect来实现。
回过头来看，cURL能执行正确，也说明了不同的客户端实现，会导致不同的效果。
总结
使用http.ServeMux注册路由时需要注意，资源是否包含下层资源，如果不包含就不要以/结尾；防止客户端遵循HTTP协议规范程度不同，而产生意外的结果。
与其说此为坑，倒不如说这是不熟悉协议的程序猿编出来的“坑”吧。
推荐阅读
【开源软件评选】快来给 Apache ServiceComb 打电话领纪念品啦
go-chassis 为 grpc-go 带来高级云原生特性
Apache ServiceComb架构演进：支持多数据中心微服务发现
更多精彩内容，关注微信公众号！
有疑问加站长微信联系（非本文作者）
