17370845950

最稳妥的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 属性设置。

• 若跳转前后域名不同（如 login.example.com → app.example.com），需确保 Cookie 的 Domain 设为 .example.com，且 SameSite 不能为 Strict
• 服务端无法通过重定向响应“注入”新 Cookie；想让跳转后带新 Cookie，必须在重定向前用 http.SetCookie 写入响应头
• 常见陷阱：在 http.Redirect 后调用 http.SetCookie —— 此时响应头已发送，无效

真正要做的事，是在调用 http.Redirect 前，把所有需要的 Cookie 全部设好。