Go ServeMux 路径尾斜杠重定向为什么影响 POST 请求

Go ServeMux 的尾斜杠重定向本身通常不会丢掉 POST 请求体：当你注册了 /upload/ 这样的子树路径，而客户端请求的是 /upload，ServeMux 会把它重定向到带尾斜杠的路径，并使用 307。307 的语义是客户端跟随跳转时继续使用原来的方法和请求体。

真正的问题在于链路中的其他一层把这个跳转改成了 301、302 或 303，或者客户端没有按 307 的语义跟随。于是服务端最终看到的可能是 GET，请求体自然也不会出现在处理函数里。排查时要先区分“ServeMux 返回了什么”和“客户端最终发送了什么”。

官方文档：https://pkg.go.dev/net/http

只要 POST 的入口路径与 ServeMux 注册模式保持一致，或者由应用明确控制 307 跳转，尾斜杠就不会神秘地吃掉请求体。先看响应状态码与 Location，再看最终请求方法。

先看路径模式为什么会触发跳转

在 ServeMux 中，以斜杠结尾的模式代表一个子树。例如 /upload/ 不只匹配一个字符串，它还覆盖以 /upload/ 开头的路径。于是 /upload/part-1 可以进入这个子树，而没有尾斜杠的 /upload 不是同一个路径。

当无尾斜杠的根路径没有单独注册，而补上斜杠后能精确匹配已注册的子树根时，ServeMux 会返回重定向响应。当前实现使用 307 临时重定向，让客户端有机会保留原来的方法、请求头和请求体。

mux := http.NewServeMux()

// 尾斜杠表示 upload 子树；/upload 本身会进入尾斜杠补全逻辑。
mux.HandleFunc("POST /upload/", func(w http.ResponseWriter, r *http.Request) {
	// 处理函数只会在最终路径带有尾斜杠时被调用。
	if _, err := io.Copy(io.Discard, r.Body); err != nil {
		http.Error(w, "读取请求体失败", http.StatusBadRequest)
		return
	}
	w.WriteHeader(http.StatusNoContent)
})

// 监听地址仅用于展示路由注册方式，生产环境应交给实际服务配置。
_ = http.ListenAndServe(":8080", mux)

这个注册方式的重点不是“POST 必须带斜杠”，而是路由模式和调用方的 URL 必须有一个稳定约定。如果客户端把数据 POST 到 /upload，它首先拿到的是跳转响应，而不是业务处理函数的响应。

为什么同样是重定向，POST 结果却可能不同

HTTP 客户端是否保留 POST，取决于重定向状态码和客户端实现。307、308 的设计目标是保留原方法和请求体；而 301、302 在不同客户端中可能被改写成 GET，303 则明确要求客户端以 GET 请求新的 URL。这样一来，后端日志会出现“第一次是 POST，第二次是 GET”，开发者就容易误以为 ServeMux 把 body 清空了。

可以把链路拆成三段观察：

1. 原始请求：客户端实际发送到哪个路径，方法是否是 POST，是否带有 Content-Length 或 Transfer-Encoding。
2. 第一响应：ServeMux 或代理返回的状态码和 Location 是否指向同一个资源的尾斜杠版本。
3. 最终请求：客户端跟随后发送的是否仍是 POST，请求体是否重新可读。

// 关闭自动跟随，先把第一跳的状态码和 Location 打出来。
client := &http.Client{
	CheckRedirect: func(req *http.Request, via []*http.Request) error {
		// 返回 ErrUseLastResponse，保留第一跳响应，便于区分 307 与其他 3xx。
		return http.ErrUseLastResponse
	},
}

body := strings.NewReader(`{"name":"demo"}`)
req, err := http.NewRequest(http.MethodPost, "http://127.0.0.1:8080/upload", body)
if err != nil {
	// 构造 URL 或请求体失败时不要继续发一个不完整请求。
	log.Fatal(err)
}
req.Header.Set("Content-Type", "application/json")

resp, err := client.Do(req)
if err != nil {
	// 网络错误与 HTTP 3xx 是两类问题，分别记录。
	log.Fatal(err)
}
defer resp.Body.Close()

fmt.Println(resp.StatusCode, resp.Header.Get("Location"))

如果这里看到的是 307 Temporary Redirect，说明 ServeMux 的尾斜杠规则正在按预期工作。下一步再打开自动跟随，观察最终请求；如果第一跳已经变成 301 或 302，就应检查反向代理、网关或中间件，而不是先改业务 handler。

三种不会误伤 POST 的路由设计

方案一：把规范 URL 直接交给调用方

上传接口如果确定使用带尾斜杠的资源路径，就让客户端直接请求 /upload/。这条路径最简单，少一次跳转，也不会依赖客户端对 3xx 的实现差异。

// API 约定使用带尾斜杠的规范入口，调用方不要先请求无斜杠路径。
mux.HandleFunc("POST /upload/", func(w http.ResponseWriter, r *http.Request) {
	// 业务代码从这里开始读取 body，不承担路径规范化职责。
	data, err := io.ReadAll(r.Body)
	if err != nil {
		http.Error(w, "读取失败", http.StatusBadRequest)
		return
	}
	fmt.Fprintf(w, "received=%d", len(data))
})

方案二：为无斜杠入口单独注册处理器

如果历史客户端已经固定使用 /upload，可以单独注册这个路径，让它成为真实入口，而不是等待 ServeMux 追加斜杠。两个入口应共享同一个处理函数，避免一边做鉴权、一边漏掉限制。

handleUpload := func(w http.ResponseWriter, r *http.Request) {
	// 两个入口共享业务处理逻辑，避免重定向改变请求方法。
	if r.Method != http.MethodPost {
		http.Error(w, "只接受 POST", http.StatusMethodNotAllowed)
		return
	}
	if _, err := io.Copy(io.Discard, r.Body); err != nil {
		http.Error(w, "读取失败", http.StatusBadRequest)
		return
	}
	w.WriteHeader(http.StatusNoContent)
}

// 无斜杠和带斜杠都直接到同一个 handler，不经过跳转。
mux.HandleFunc("POST /upload", handleUpload)
mux.HandleFunc("POST /upload/", handleUpload)

双入口不是永远更好。它会增加公开 URL 的数量，也可能让缓存、签名或幂等键出现两个版本。如果接口需要唯一规范 URL，优先使用方案一或方案三，并在文档中明确调用路径。

方案三：应用明确返回 307

需要把旧路径迁移到新路径时，可以由应用显式返回 307，并把重定向策略作为接口契约的一部分。这样状态码不会在代理层被“顺手”换掉，客户端也能按照保留方法和请求体的语义处理。

// 旧入口明确使用 307，把方法和 body 的保留交给客户端。
mux.HandleFunc("/upload", func(w http.ResponseWriter, r *http.Request) {
	// 只拼接固定路径，不把用户输入拼进 Location，避免产生错误目标。
	http.Redirect(w, r, "/upload/", http.StatusTemporaryRedirect)
})

mux.HandleFunc("POST /upload/", handleUpload)

排查时优先看哪几个信号

不要只在最终 handler 里打印 r.Method 和 r.URL.Path。如果请求已经被改写，那里只能看到最后一跳。建议在网关和 Go 服务入口同时记录以下字段：

还有一个容易忽略的边界：ServeMux 的 307 只能解决路由器返回的这一跳。若前面有 TLS 终止、域名规范化、路径前缀剥离或对象存储代理，任何一层都可能再次发起重定向。应让接口的规范路径、状态码和方法保留规则在整条链路上保持一致。

结论：先统一规范路径，再决定是否允许跳转

Go ServeMux 的尾斜杠规则不是随机删除 POST body，而是把 /upload 规范化到已注册的 /upload/。ServeMux 当前返回 307，客户端正确跟随时应继续使用 POST 并保留请求体。

工程上可以按这个顺序处理：

1. 客户端直接使用已注册的规范路径，消除第一次跳转。
2. 必须兼容旧路径时，为无斜杠入口单独注册，或显式返回 307。
3. 看到 POST 变 GET 时，先记录第一跳状态码、Location 和最终方法，再排查代理与客户端。

常见追问

ServeMux 的尾斜杠重定向只影响 POST 吗？

不是。任何需要携带方法或请求体的请求都值得关注，PUT、PATCH 以及带流式 body 的请求同样应确认客户端如何跟随 3xx。GET 通常看不到 body 丢失问题，但仍会多一次网络往返。

把路径改成 /upload/{$} 有什么用？

它用于只匹配带尾斜杠的这个固定路径，而不是整个 /upload/ 子树。它适合需要精确区分根路径和下级资源的场景，但不会替代对无斜杠入口的兼容设计。

能不能在 handler 里读取一次 body 后再重定向？

不建议把业务读取和路径规范化混在一起。重定向应尽可能发生在读取 body 之前，并使用明确的 307；如果已经读取或消费了流，后续跳转未必能重新构造同一份请求体。