Go ServeMux 为什么尾斜杠重定向导致方法变化

ServeMux 补尾斜杠时返回的是重定向响应，方法变化通常发生在客户端发起后续请求时。若首跳是 301、302 或 303，Go http.Client 会把非 GET、HEAD 方法改成 GET，并且不携带正文；若是 307、308，则按保留方法与正文的规则处理，但正文必须能够重放。

不能只凭路径多了一个斜杠，就断定 POST 必然变成 GET。Go 1.24.0 的 ServeMux 源码使用 301，而 Go 1.26.0 及当前源码的对应分支使用 307。排查时先取得实际首跳状态码，再核对服务端版本、代理和客户端策略。

Go 官方地址：https://go.dev/

业务处理器看到的可能已经是第二次请求

假设注册的是 /submit/，调用方发送 POST /submit。没有另外注册 /submit 时，ServeMux 会为子树根路径补斜杠并返回 Location。业务处理器可能尚未执行，客户端就已收到重定向；自动跟随之后，处理器看到的是新请求。

因此“客户端代码写了 POST”和“处理器日志里是 GET”并不矛盾。只看最终响应甚至可能只看到 405，而看不到之前的 301。需要把首跳状态、Location、后续方法和最终路由分开记录。

先停掉自动跟随，观察首跳响应

下面给出可自行复现的服务端和诊断客户端。两段都是独立 main 程序，应放在不同目录；不要合成同一个包的两个 main。本文没有执行服务器或网络示例，不把推导现象当作实测日志。

package main

import (
    "fmt"
    "log"
    "net/http"
    "time"
)

func main() {
    mux := http.NewServeMux()
    mux.HandleFunc("/submit/", func(w http.ResponseWriter, r *http.Request) {
        // 展示处理器实际看到的方法；此处不执行任何业务写入。
        fmt.Fprintf(w, "handler_method=%s path=%s\n", r.Method, r.URL.Path)
    })
    srv := &http.Server{
        Addr: "127.0.0.1:8099",
        Handler: mux,
        ReadHeaderTimeout: 3 * time.Second,
    }
    // 只监听本地演示端口，结束演示时停止该进程。
    log.Fatal(srv.ListenAndServe())
}

服务端启动后，另一个目录运行下面的诊断客户端。ErrUseLastResponse 让 Go 客户端停止跟随，并将首跳响应交回调用方。响应体仍由调用方关闭。

package main

import (
    "fmt"
    "log"
    "net/http"
    "strings"
    "time"
)

func main() {
    client := &http.Client{
        Timeout: 5 * time.Second,
        CheckRedirect: func(req *http.Request, via []*http.Request) error {
            // 保留首跳响应，让调用方查看真正的状态码与 Location。
            return http.ErrUseLastResponse
        },
    }
    req, err := http.NewRequest(
        http.MethodPost, "http://127.0.0.1:8099/submit",
        strings.NewReader("note=demo"))
    if err != nil {
        log.Fatal(err)
    }
    req.Header.Set("Content-Type", "application/x-www-form-urlencoded")
    resp, err := client.Do(req)
    if err != nil {
        log.Fatal(err)
    }
    defer resp.Body.Close()
    fmt.Printf("status=%d location=%q\n",
        resp.StatusCode, resp.Header.Get("Location"))
}

这次先读打印出的 status 和 location，不预设每个版本都是 301。Location 指向 /submit/ 才能支持“补斜杠”这个判断；如果指向登录页、另一个主机或 HTTPS 地址，应转查代理、鉴权或其他中间件。

按实际状态码解释方法为什么变化

这里限定为 Go 标准客户端的行为，不把其他 HTTP 工具的选项习惯当成相同规则。比较源码版本是为了说明历史差异，并不意味着只要升级就能解决整条链路：旧二进制、兼容模式、网关和自定义重定向都可能继续返回另一种状态。

若当前标准 ServeMux 首跳已经是 307，却仍观察到 GET，应逐跳检查响应，不能继续把原因归到当前 ServeMux 的 301 分支。尤其要确认请求是否先经过反向代理，以及日志是否混入了浏览器另发的请求。

优先统一接口路径，必要时显式注册无斜杠入口

如果接口约定的路径是 /submit/，调用方直接使用这个完整路径，能省去重定向及正文重放。如果接口应同时接受两种形式，可把它们直接交给同一个处理器：

// 放在已有 main 中，替换原来的注册；不要重复注册相同模式。
handleSubmit := func(w http.ResponseWriter, r *http.Request) {
    if r.Method != http.MethodPost {
        w.Header().Set("Allow", http.MethodPost)
        http.Error(w, "仅支持 POST", http.StatusMethodNotAllowed)
        return
    }
    // 演示只返回确认，不产生业务副作用。
    w.WriteHeader(http.StatusNoContent)
}
mux.HandleFunc("/submit", handleSubmit)
mux.HandleFunc("/submit/{$}", handleSubmit)

其中 {$} 是现代 ServeMux 的精确路径结尾写法，要求 Go 1.22 或后续路由语法，不能放进启用了旧路由兼容模式的项目后仍期待同样匹配。它让 /submit/ 对应一个入口，而不是连同所有更深层路径都交给处理器。

直接注册后，两种请求都可以避免这一层补斜杠跳转，但要确定这符合服务契约。签名、缓存键或鉴权如果依赖精确 URL，还需要一起约定规范形式；不要临时通过修改 Request.Method 伪装已经丢失的正文。

需要保留重定向时，再考虑正文能否重放

307、308 解决的是方法保持语义，不会让任意流自动变成可重复读取的数据。Go 客户端遇到非空正文、但缺少 GetBody 的情形，可能直接把重定向响应返回给调用方。前面的 strings.NewReader 会被 NewRequest 识别为可重新创建的正文来源，但自定义 io.Reader、管道和实时流不应套用这个结论。

如果自己必须发出重定向，应明确使用与接口语义一致的状态，而不是默认套 301。客户端还要确认目标与重放权限。对一次性上传，直接调用规范 URL 通常比依赖重放更易管理；若业务具有副作用，重试与重定向也需要结合幂等设计，不能因请求方法没变就假定重复执行没有代价。

用两个路径复查，并保留首跳观察能力

修复后分别发送带斜杠和不带斜杠的请求，观察它们是否按选定契约直达处理器或返回预期重定向，再检查最终方法与正文是否完整。若预期只支持一种路径，则错误入口的返回也应明确，而不是以“最终成功”掩盖隐式跳转。

为什么最后看到的是 405 而不是 301？

客户端可能已经自动跟随，最后的 GET 没匹配 POST 路由。先停止跟随，取出中间响应。

给 POST 路由补一个斜杠就一定保留正文吗？

不一定，要看实际状态、客户端策略和正文重放条件。最直接的办法是按服务约定调用正确路径。

/submit/ 为什么还能匹配更长路径？

普通尾斜杠模式具有子树语义。现代 ServeMux 若只想匹配该路径结尾，可按业务需要使用 /submit/{$}。

路由规则见 ServeMux 文档；客户端重定向规则见 官方 client.go；历史与当前状态码分别见 Go 1.24.0 server.go 和 当前 server.go。