最稳妥的HTTP 302重定向需显式传入http.StatusFound状态码并使用绝对URL；避免已写响应体后调用，手动设置Location头时须先设头再调用WriteHeader，带参URL应通过url.URL和url.Values安全构造。
HTTP 302 重定向怎么写最稳妥
Go 的 http.Redirect 是最常用也最容易出错的跳转方式。它默认用 http.StatusFound（302），但如果你没显式指定状态码，又在生产环境用了反向代理（比如 Nginx 或 Cloudflare），可能遇到缓存或 Referer 丢失问题。
- 务必传入明确的状态码，不要依赖默认值；302 适合临时跳转，301 仅用于永久迁移且需谨慎（浏览器和 CDN 会强缓存）
-
http.Redirect会自动设置Location头并写入响应体（含 HTML 跳转提示），若你已调用过w.WriteHeader或写过响应体，会 panic：「http: multiple response.WriteHeader calls」 - 目标 URL 必须是绝对路径或完整 URL；相对路径（如
/login）会被自动补全为当前请求协议+Host，但若请求头 Host 被篡改或代理未透传，结果不可靠
func handler(w http.ResponseWriter, r *http.Request) {
// ✅ 正确：显式传状态码，用完整 URL 避免歧义
http.Redirect(w, r, "https://example.com/dashboard", http.StatusFound)
// ❌ 错误：没传状态码（虽能运行，但语义模糊）
// http.Redirect(w, r, "/dashboard", http.StatusFound)
// ❌ 错误：已写响应体后再重定向
// w.Write([]byte("done"))
// http.Redirect(w, r, "/login", http.StatusFound) // panic!
}
手动设置 Location 头与状态码的适用场景
当需要精细控制响应头（比如加 Cache-Control: no-cache、自定义 Vary，或避免 http.Redirect 自动写 HTML 提示内容）时，应绕过 http.Redirect，手动操作。
- 必须在调用
w.Header().Set("Location", ...)前未写入任何响应体，否则无效 - 手动设置后必须调用
w.WriteHeader(statusCode)，不能只设头不写状态码（否则默认 200） - 307 和 308 要求方法和请求体保持不变，适合 POST 表单重定向；但注意：浏览器对 308 支持度略低于 307（Chrome/Firefox/Edge 均支持，Safari 15.4+ 支持）
func postHandler(w http.ResponseWriter, r *http.Request) {
if r.Method != http.MethodPost {
w.WriteHeader(http.StatusMethodNotAllowed)
return
}
w.Header().Set("Location", "https://api.example.com/v2/submit")
w.Header().Set("Cache-Control", "no-cache")
w.WriteHeader(http.StatusTemporaryRedirect) // 307
// 不写响应体，符合 307 语义
}
重定向到带查询参数的 URL 怎么拼接才安全
直接字符串拼接 ?a=1&b=2 极易引入 XSS 或编码错误。Go 标准库提供 url.URL 和 url.Values 来安全构造。
- 永远用
url.Parse解析基础 URL，再用Query().Set添加参数，避免手动拼问号和 & - 用户输入的参数值必须经
url.QueryEscape编码；url.Values的Encode()方法已内置此逻辑 - 如果原始 URL 已含查询参数，
url.Parse会保留它们，Query().Set会覆盖同名键，Add可追加多值
func redirectWithParams(w http.ResponseWriter, r *http.Request) {
u, _ := url.Parse("https://example.com/search")
q := u.Query()
q.Set("q", r.URL.Query().Get("q")) // 用户搜索词，已由 Parse 自动解码
q.Set("from", url.QueryEscape("go-app")) // 确保特殊字符被编码
u.RawQuery = q.Encode()
http.Redirect(w, r, u.String(), http.StatusFound)
}
为什么重定向后 Cookie 没带上？
不是 Go 的问题，而是浏览器策略：重定向响应本身不携带 Cookie，后续跳转请求是否发送 Cookie，取决于原始请求的 Cookie 头、目标域名是否匹配，以及 SameSite 属性设置。
立即学习“go语言免费学习笔记（深入）”；
- 若跳转前后域名不同（如
login.example.com → app.example.com），需确保 Cookie 的Domain设为.example.com，且SameSite不能为Strict - 服务端无法通过重定向响应“注入”新 Cookie；想让跳转后带新 Cookie，必须在重定向前用
http.SetCookie写入响应头 - 常见陷阱：在
http.Redirect后调用http.SetCookie—— 此时响应头已发送，无效
真正要做的事，是在调用 http.Redirect 前，把所有需要的 Cookie 全部设好。
