Go CookieJar 怎么让重定向后的请求继续携带会话 Cookie

我第一次排查 Go 的登录跳转时，看到入口接口返回了 Set-Cookie，却发现最终页面像没有登录。真正容易漏掉的点是：Cookie 不会因为请求发生了重定向就自动跨客户端保存。要让同一条重定向链延续会话，应创建一个 cookiejar.Jar，再把它挂到同一个 http.Client 上。

官方文档：https://pkg.go.dev/net/http/cookiejar

最小做法：jar, _ := cookiejar.New(nil)，然后使用 &http.Client{Jar: jar} 发起入口请求。只要 Cookie 的 Domain、Path、Secure 与目标 URL 匹配，客户端跟随重定向时就能继续带上会话 Cookie。

先把问题缩小到同一个 HTTP 客户端

这篇只讨论同一个 Go 客户端从 /start 跳到 /home 的场景。服务端在入口响应里设置 sid，客户端接住它，再把匹配的 Cookie 放到后续请求中；不讨论浏览器的 SameSite 策略，也不讨论把 Jar 持久化到磁盘。

这条链里有三个对象：服务端负责发出 Set-Cookie 和 Location，cookiejar.Jar 负责按 URL 保存和筛选 Cookie，http.Client 负责把 Jar 应用到请求与重定向过程。少了 Client 上的 Jar，单独解析响应头并不能让下一跳自动带 Cookie。

创建 CookieJar，并把它挂在 Client 上

cookiejar.New(nil) 创建的是内存 Jar，适合短生命周期的客户端会话。核心不是每次请求手写 Cookie 请求头，而是让所有相关请求复用同一个 Client。

package main

import (
    "fmt"
    "net/http"
    "net/http/cookiejar"
    "net/http/httptest"
)

func main() {
    mux := http.NewServeMux()
    mux.HandleFunc("/start", func(w http.ResponseWriter, r *http.Request) {
        // 入口响应设置会话 Cookie，并把客户端引向受保护路径。
        http.SetCookie(w, &http.Cookie{Name: "sid", Value: "demo-123", Path: "/"})
        http.Redirect(w, r, "/home", http.StatusFound)
    })
    mux.HandleFunc("/home", func(w http.ResponseWriter, r *http.Request) {
        // 只有请求带上 sid，才把它视为已延续的会话。
        cookie, err := r.Cookie("sid")
        if err != nil {
            http.Error(w, "missing sid", http.StatusUnauthorized)
            return
        }
        fmt.Fprintf(w, "welcome %s", cookie.Value)
    })

    server := httptest.NewServer(mux)
    defer server.Close() // 关闭测试服务，避免资源泄漏。

    jar, err := cookiejar.New(nil)
    if err != nil {
        panic(err) // 示例中直接终止；生产代码应返回或记录错误。
    }
    client := &http.Client{Jar: jar}

    response, err := client.Get(server.URL + "/start")
    if err != nil {
        panic(err)
    }
    defer response.Body.Close() // 读取完最终响应后关闭响应体。

    fmt.Println(response.Status)
    fmt.Println(response.Request.URL.Path)
}

这里的入口请求只调用一次 client.Get，但 Client 会处理重定向链。最终 Handler 能读到 sid，说明 Cookie 已由 Jar 接住并匹配到了 /home。真实项目里把 panic 换成错误返回，并按业务需要读取响应体。

用两跳小项目确认会话是否延续

排查时我会先做一个最小两跳服务，而不是直接在复杂登录流程里猜。第一跳只负责设置 Cookie 和返回跳转地址，第二跳只检查 Cookie。这样可以把“服务端是否设置”“客户端是否挂 Jar”“路径是否匹配”分开看。

如果最终状态是 200 OK，而第二个 Handler 读到了 sid，说明基础配置成立。若最终请求停在入口，先看是否自定义了 CheckRedirect；如果最终请求到达但没有 Cookie，再检查 Jar 和 Cookie 属性。

重定向后仍然没有 Cookie，先查这四个边界

第一，是否复用了同一个 Client。每次调用都新建 http.Client，就等于换了会话容器；Jar 也会随之丢失。

第二，Domain 和 Path 是否匹配。Cookie 的作用域决定它能发给哪些 URL。入口设置了过窄的 Path，跳到另一个路径后自然看不到它。

第三，Secure 是否与协议一致。标记为 Secure 的 Cookie 不应期待在普通 HTTP 测试地址上发送。本地测试要让协议和 Cookie 属性保持一致。

第四，是否主动改写了重定向策略。CheckRedirect 可以阻止或接管跳转；它改变的是 Client 的重定向行为，不会替代 Jar 的 Cookie 匹配。

接入业务代码时的验收清单

把 Jar 放在需要共享会话的 Client 上，并在整个登录到业务请求的生命周期内复用这个 Client。不要把不同账号共用一个 Jar，也不要为了“保险”在每次请求中同时手工拼接 Cookie。请求完成后关闭响应体；如果业务需要长期登录，再单独设计受保护的持久化方案，因为标准 cookiejar 本身是内存实现。

常见追问

CookieJar 会把 Cookie 永久保存吗？不会。标准 Jar 是内存实现，进程结束后内容消失；长期会话要另行设计安全存储。

为什么手工给第一跳加 Cookie 仍然不行？请求头只影响这一跳；服务端新发的 Set-Cookie 仍需要由 Client 的 Jar 接收，后续 URL 还要满足作用域匹配。

能不能直接读取 Jar 里的 Cookie？可以用 jar.Cookies(u) 查看某个 URL 能匹配到的 Cookie，但这只是诊断某个 URL，不等于所有域名和路径共享。