Go HTTP 重定向为什么改变了 POST 请求方法

Go 的 http.Client 并不是收到 3xx 就原样重发请求。对 POST 来说，301、302 和 303 会让后续请求改成 GET，同时丢掉请求体；只有 307、308 才表达“方法和 body 一起保留”。因此登录回调、文件上传或支付提交遇到重定向时，先看状态码，再看请求体是否可重放。

要保留 POST 语义，服务端应返回 307/308，客户端要用 http.NewRequest 创建可重放的 body，并通过 CheckRedirect 限制目标地址。对 301/302/303，不能指望 Go 自动替你保留 POST。

为什么 301、302、303 会改变方法

Client.Do 在跟随重定向前会调用 CheckRedirect。如果没有自定义策略，Go 会沿用默认规则：当原方法不是 GET 或 HEAD 时，301、302、303 的下一次请求改成 GET，body 也不再发送。这是为了兼容长期存在的 Web 重定向习惯，不是服务端把 POST “神秘改写”了。

所以如果原请求携带 name=alice 或 JSON 数据，目标地址收到的通常是一个没有 body 的 GET。只检查最终响应码很容易漏掉这个问题；在服务端日志中同时记录 method、Content-Length 和 Location，才能确认数据是否在跳转处消失。

需要保留 POST 时使用 307 或 308

307 Temporary Redirect 和 308 Permanent Redirect 的语义是保留原方法与 body。Go 只有在请求体可以重新读取时才会这样做。http.NewRequest 对 []byte、bytes.Buffer、bytes.Reader 等常见类型会设置 GetBody；自定义流式 reader 通常没有这个能力。

payload := []byte(`{"name":"alice"}`) // 用可重复读取的内存数据创建请求体
req, err := http.NewRequest(http.MethodPost, "https://api.example.com/submit", bytes.NewReader(payload))
if err != nil {
    return err
}
req.Header.Set("Content-Type", "application/json")

resp, err := (&http.Client{}).Do(req) // 307/308 可在 GetBody 存在时保留 POST
if err != nil {
    return err
}
defer resp.Body.Close() // 读取响应后关闭 body，便于连接复用

如果用的是一次性流，收到 307/308 后 Go 会因为无法安全重发而停止继续跳转，调用方拿到当前响应。这里不要简单把流强行复制；应先把需要重试的请求体落到可重放的缓冲区，或让服务端改用不需要重定向的入口。

用 CheckRedirect 阻止错误跳转

需要审查目标地址、记录跳转链，或不接受方法变化时，可以自定义 CheckRedirect。回调里的 req 是“准备发送的下一请求”，via 保存此前已经发出的请求；因此检查 req.Method 和 req.URL.Host 比只看初始请求更可靠。

client := &http.Client{
    CheckRedirect: func(next *http.Request, via []*http.Request) error {
        // 非同一主机的跳转先停下，避免把业务请求带到未知目标
        if len(via) > 0 && next.URL.Host != via[0].URL.Host {
            return http.ErrUseLastResponse
        }
        // POST 被 301/302/303 改成 GET 时，交给上层决定是否重试
        if via[0].Method == http.MethodPost && next.Method != http.MethodPost {
            return http.ErrUseLastResponse
        }
        return nil
    },
}

返回 http.ErrUseLastResponse 时不会发送下一请求，最近一次响应会返回给调用方，且其 body 仍由调用方负责关闭。若只是返回普通 error，Do 会把它包装为 *url.Error；这适合把跳转视为失败，但不适合还想读取 3xx 响应体的场景。

生产代码的重定向检查清单

还要留意响应 body 的生命周期：无错误返回的响应需要关闭；被 CheckRedirect 拦下的最后响应也要由调用方关闭。最终的修复通常不是“把所有 302 改成 307”这么简单，而是让服务端的状态码表达真实语义，并让客户端只跟随可信、可重放的请求。

常见问题

Go 的 302 一定会把 POST 变成 GET 吗？

对 Go 客户端默认重定向规则，非 GET/HEAD 方法会变成 GET。自定义 CheckRedirect 可以阻止它；是否让服务端改成 307/308则取决于接口语义。

307 和 308 只差临时与永久吗？

客户端保留方法与 body 的处理核心相同，主要区别在服务器对重定向持续性的表达。永久迁移仍应确认缓存、客户端和代理的行为。

为什么 307 后请求没有继续发出？

常见原因是 body 没有 GetBody，Go 无法安全地再次读取一次性流。改用可重放 reader，或取消自动跟随后自行处理。

资料：net/http.Client.Do、Client.CheckRedirect 与 Go 官方 client.go 源码。