Go Redirect 为什么 POST 后变成 GET

Go 里的 http.Redirect 不会直接把 POST 变成 GET，真正决定后续请求方法的是重定向状态码和客户端的跟随策略。使用 http.Client 自动跟随时，301、302、303 通常会让 POST 变成没有请求体的 GET；307、308 才表达“继续使用原方法”。

先从状态码判断 POST 会不会被改写

服务端调用 http.Redirect 时，第四个参数就是响应状态码。客户端收到 301、302 或 303 后，Go 的 Client 会把后续请求改成 GET（原请求是 HEAD 时则使用 HEAD），并且不再携带原请求体。这个行为是客户端的重定向策略，不是 http.Redirect 把 r.Method 改掉了。

如果服务端返回 307 或 308，Go 客户端会尝试保留原方法和请求体。这个选择更贴近“资源临时/永久换了地址”的语义，但它也意味着 POST 可能再次执行，支付、写入、发送消息等非幂等操作不能只靠换状态码解决。

用最小服务端示例确认 Redirect 的状态码

下面的服务端同时提供两个入口：一个用 302 跳转，一个用 307 跳转。它们的处理函数都只负责返回重定向响应，方法变化发生在客户端的下一跳。

package main

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

func redirect302(w http.ResponseWriter, r *http.Request) {
    // 302 让 Go Client 在跟随时把 POST 改成 GET。
    http.Redirect(w, r, "/result", http.StatusFound)
}

func redirect307(w http.ResponseWriter, r *http.Request) {
    // 307 表达临时迁移，要求后续请求保留原方法和请求体。
    http.Redirect(w, r, "/result", http.StatusTemporaryRedirect)
}

func result(w http.ResponseWriter, r *http.Request) {
    // 回显下一跳方法，便于区分是服务端还是客户端改变了语义。
    fmt.Fprintf(w, "method=%s\\n", r.Method)
}

func main() {
    mux := http.NewServeMux()
    mux.HandleFunc("/redirect-302", redirect302)
    mux.HandleFunc("/redirect-307", redirect307)
    mux.HandleFunc("/result", result)
    // 示例服务只监听本地端口，生产环境应由正式服务配置监听地址。
    log.Fatal(http.ListenAndServe(":8080", mux))
}

如果客户端向 /redirect-302 发 POST，最终的 /result 会看到 GET；向 /redirect-307 发 POST，最终仍应看到 POST。这里的结果是 HTTP 语义推导，正式排查时要同时记录客户端的重定向链。

用 CheckRedirect 观察 Go Client 的每一跳

http.Client 默认会自动跟随重定向。把 CheckRedirect 配置上，可以在下一跳真正发出前查看它的 URL、方法和上一跳数量；这比只看最终响应更容易发现 POST 已经被改写。

package main

import (
    "bytes"
    "fmt"
    "io"
    "log"
    "net/http"
)

func main() {
    body := []byte(`name=go`)
    req, err := http.NewRequest(http.MethodPost, "http://127.0.0.1:8080/redirect-302", bytes.NewReader(body))
    if err != nil {
        log.Fatal(err)
    }
    req.Header.Set("Content-Type", "application/x-www-form-urlencoded")

    client := &http.Client{
        CheckRedirect: func(next *http.Request, via []*http.Request) error {
            // next 是即将发送的请求，via 能看见已经走过的请求链。
            fmt.Printf("redirect #%d: %s %s\\n", len(via), next.Method, next.URL)
            return nil // 继续使用默认的自动跟随流程。
        },
    }

    resp, err := client.Do(req)
    if err != nil {
        log.Fatal(err)
    }
    defer resp.Body.Close() // 读取完响应后关闭 Body，避免连接无法复用。

    result, err := io.ReadAll(resp.Body)
    if err != nil {
        log.Fatal(err)
    }
    fmt.Printf("status=%s body=%s", resp.Status, result)
}

这个例子使用 bytes.Reader 创建请求体，http.NewRequest 能为常见标准库 body 设置 GetBody，因此 307/308 跟随时有机会重建请求体。换成一次性流、实时上传或不可重复读取的自定义 Reader 后，不要假设客户端总能安全重放。

需要保留 POST 时改成 307 或 308

如果目标是“把同一个写请求交给新地址”，服务端应返回 307 或 308，客户端也应使用 NewRequest 加 Client.Do，而不是把所有请求都包成 Get。但保留方法并不等于自动获得幂等性：网络重试或客户端重定向都可能导致服务端再次处理。

func preservePost(w http.ResponseWriter, r *http.Request) {
    // 307 保留 POST 语义；调用方仍需设计重复提交保护。
    http.Redirect(w, r, "https://api.example.test/v2/orders", http.StatusTemporaryRedirect)
}

真正的写接口还应结合幂等键、服务端去重或业务状态检查。若请求体含一次性流、文件上传或带副作用的动作，先确认客户端和中间层都支持重放，再采用 307/308；否则宁可返回明确错误，让调用方重新构造请求。

不想自动跳转时保留原始响应

有些客户端只想判断“服务端要求跳转到哪里”，不希望 Go 静默发出第二个请求。这时可以让 CheckRedirect 返回 http.ErrUseLastResponse。Go 会返回最近一次响应，并保留它的 Body，调用方负责关闭。

client := &http.Client{
    CheckRedirect: func(next *http.Request, via []*http.Request) error {
        // 返回原始 3xx 响应，避免未经业务确认就再次发送 POST。
        return http.ErrUseLastResponse
    },
}

如果要直接拒绝跨主机、跨协议或超过指定跳数的跳转，也可以在回调里返回自定义错误。此时 Do 会返回 *url.Error，并且重定向前的响应体已被关闭；日志中应保留原始 URL、下一跳 URL 和状态码，便于定位配置问题。

排查时按这四步收敛问题

1. 记录第一响应的状态码和 Location，先确认是 302、303 还是 307、308。
2. 在 CheckRedirect 中打印 next.Method、next.URL 和 len(via)，不要只观察最终响应。
3. 如果业务要求保留 POST，检查请求体是否有 GetBody 或者能安全重建，并评估重复执行风险。
4. 如果跳转需要业务确认，返回 http.ErrUseLastResponse，把 3xx 交给上层决定。

常见问题

为什么服务端日志里的第一条请求仍然是 POST？

第一条请求确实可以是 POST；变化通常发生在客户端跟随 Location 发出的第二条请求。要看两条请求的状态码、URL 和方法，不能只看入口日志。

把 302 换成 307 就一定安全吗？

不一定。307 会保留写方法，重定向或重试可能重复执行副作用。需要配合幂等设计、可重建请求体和明确的跨主机信任边界。

为什么我设置了 307，方法仍然没有保留？

检查是否真正命中了 307、客户端是否被中间层改写，以及请求体是否能重建。也要确认代码使用的是自定义 http.Client，而不是另一个仍在自动跟随的客户端。

所以，Go Redirect 后 POST 变成 GET 通常不是异常，而是 301/302/303 的预期客户端行为。先按状态码判断语义，再用 CheckRedirect 观察每一跳；需要保留 POST 时选择 307/308，并把请求体重放和重复提交一起纳入设计。