Go 的 http.Client 默认自动重定向存在 SSRF、循环跳转等风险，应通过显式配置 CheckRedirect 函数控制跳转逻辑，返回 http.ErrUseLastResponse 可安全终止重定向并保留响应体。
Go 的 http.Client 默认会自动重定向，但不安全
默认情况下，http.DefaultClient 会对 301/302/307/308 响应自动发起新请求，最多 10 次。这看似省心，实则埋雷：比如重定向到内网地址（SSRF）、循环跳转、或携带敏感头泄露凭证。
真正可控的做法是显式配置 CheckRedirect 函数，由你决定“要不要跳”“跳几次”“跳到哪儿”。它不是开关，而是拦截器 —— 每次准备跳转前都会被调用一次。
-
CheckRedirect是一个函数类型：func(req *http.Request, via []*http.Request) error -
req是即将发出的重定向请求；via是已发出的请求链（含原始请求），可用于判断跳转深度或路径 - 返回
nil表示允许跳转；返回非nil错误（如http.ErrUseLastResponse）则中断并返回当前响应
http.ErrUseLastResponse 是终止重定向最干净的方式
很多人直接 return errors.New("stop")，结果得到 net/http: invalid redirect policy 错误。这是 Go 的校验机制在报错 —— 它只接受特定错误值来表示“别跳了，就用上一次的响应”。
正确做法是返回 http.ErrUseLastResponse。它是个预定义变量，不是字符串，也不是自定义错误。
立即学习“go语言免费学习笔记（深入）”；
- 返回
http.ErrUseLastResponse：停止重定向，resp.Body是最后一次重定向响应体（比如 302 的响应） - 返回其他错误（如
fmt.Errorf("too many hops")）：整个请求失败，resp为nil - 想保留原始请求头（如
Authorization）？默认不会透传。需手动复制：req.Header = via[0].Header.Clone()
常见重定向控制场景与写法
实际项目里，重定向逻辑往往不是“全开”或“全关”，而是按目标域名、跳转次数、状态码做细粒度判断。
- 限制最多 3 次跳转：
if len(via) >= 3 { return http.ErrUseLastResponse } - 禁止跳转到内网 IP：
if strings.HasPrefix(req.URL.Host, "192.168.") || req.URL.Host == "localhost" { return http.ErrUseLastResponse } - 只允许跳转到同一域名：
if req.URL.Host != via[0].URL.Host { return http.ErrUseLastResponse } - 对 307/308 保持方法不变，但对 301/302 强制转 GET（标准行为），无需额外处理 —— Go 默认已遵循 RFC
自定义 http.Client 时别漏掉 Timeout 和 Transport
CheckRedirect 只管跳不跳，不管连不连得上、等不等得及。如果重定向链里某个中间地址响应极慢，整个请求就会卡住，直到超时（默认无超时）。
- 必须设置
Timeout（如30 * time.Second），否则可能永久阻塞 - 若需复用连接、控制 TLS、加代理，记得配
Transport；否则会 fallback 到http.DefaultTransport，而它的MaxIdleConns等参数可能不符合高并发预期 - 别把
CheckRedirect写成闭包却意外捕获了大对象（比如整个数据库连接池），容易引发内存泄漏
重定向逻辑看着简单，但 via 切片里藏着完整请求链，req.URL 在每次回调里都已是下一个目标地址 —— 这两点最容易看反，一写错就绕进死循环或者放行恶意跳转。
