Go的http.Client默认自动处理301、302、307、308重定向，最多10次跳转；通过设置CheckRedirect可自定义策略，如限制跳转次数、域名或记录路径；返回http.ErrUseLastResponse可禁用自动跳转并手动处理状态码；实际开发中应校验URL、防止SSRF、显式处理API重定向，并注意请求方法和Cookie的传递行为。
在Go语言中处理HTTP重定向和状态码是构建可靠网络请求逻辑的重要部分。默认情况下，net/http 包会自动处理常见的重定向状态码，比如 301、302、307 和 308。但实际开发中，我们往往需要更精细的控制，例如自定义重定向策略、记录跳转过程或阻止某些类型的跳转。
理解默认的重定向行为
Go 的 http.Client 默认启用了重定向机制，通过其字段 CheckRedirect 控制。默认策略允许最多 10 次连续重定向，超过则返回错误。
常见的重定向状态码包括：
- 301 Moved Permanently：目标资源已永久移动到新位置
- 302 Found：临时重定向，大多数客户端会以 GET 方法访问新地址（即使原请求是 POST）
- 307 Temporary Redirect：临时重定向，要求保持原始请求方法和请求体
- 308 Permanent Redirect：永久重定向，同样要求保留原始方法和请求体
注意：302 和 303 可能导致 POST 请求被转为 GET，而 307 和 308 不会改变请求方法，这对表单提交等场景很重要。
立即学习“go语言免费学习笔记（深入）”；
自定义重定向策略
通过设置 http.Client.CheckRedirect 函数，可以完全控制重定向逻辑。该函数接收三个参数：当前请求、将要跳转到的请求切片（按顺序）、以及跳转次数。
示例：限制只允许特定域名内的重定向，并记录跳转路径：
client := &http.Client{
CheckRedirect: func(req *http.Request, via []*http.Request) error {
if len(via) >= 3 {
return errors.New("too many redirects")
}
if req.URL.Hostname() != "example.com" {
return errors.New("redirects to another domain not allowed")
}
log.Printf("Redirecting to: %s", req.URL)
return nil
},
}
如果函数返回非 nil 错误，重定向将被中断，且该错误会传递给调用方。返回 http.ErrUseLastResponse 则表示使用最后一次响应（即不继续跳转），但仍返回响应结果。
手动发起请求并分析状态码
如果你希望完全禁用自动重定向，以便自己处理每个响应的状态码，可以将 Client.CheckRedirect 设置为始终返回错误，或者使用一个不带重定向功能的客户端。
示例：禁用重定向并手动判断是否为重定向状态：
client := &http.Client{
CheckRedirect: func(req *http.Request, via []*http.Request) error {
return http.ErrUseLastResponse
},
}
resp, err := client.Get("https://httpbin.org/redirect/1")
if err != nil {
log.Fatal(err)
}
defer resp.Body.Close()
switch resp.StatusCode {
case 301, 302, 307, 308:
location := resp.Header.Get("Location")
log.Printf("Received redirect to: %s", location)
// 可在此处决定是否手动跟进
default:
log.Printf("Final status: %d", resp.StatusCode)
}
这种方式适用于爬虫、安全检测或需要精确控制流程的场景。
开发实践建议
在实际项目中处理重定向时，应考虑以下几点：
- 明确业务是否允许跨域重定向，防止信息泄露或跳转到恶意站点
- 对用户可控的URL进行重定向时，做好输入校验，避免SSRF漏洞
- 对于API调用，建议关闭自动重定向，由程序显式处理跳转逻辑
- 记录重定向链有助于调试和监控异常跳转行为
- 注意 Cookie 和认证头在重定向中的传递规则，必要时手动管理
基本上就这些。Go 提供了足够灵活的接口来应对各种重定向需求，关键是根据具体场景选择合适的策略。不复杂但容易忽略的是，默认行为可能改变请求方法，这一点在设计接口客户端时必须留意。
