Go http.CookieJar隔离多用户会话状态的实现方式

在一个服务里代替多个用户访问同一个站点时，最容易被忽略的共享状态就是 Cookie。把一个全局 http.Client 和一个 cookiejar.Jar 交给所有用户，登录请求写入的会话 Cookie 就可能被下一个用户带走。表现通常是偶发的“查到了别人的数据”、登录态忽然变化，或者问题只在并发压测时出现。

稳妥的做法是：以业务用户为边界创建独立的 cookiejar.Jar，再让该用户的 http.Client 始终持有这一个 Jar。Cookie 的隔离靠 Jar 实例完成，连接复用则交给 Transport；两者不要混成一个全局会话容器。

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

影响面：共享 Jar 会把用户边界变成竞态

http.Client 的 Jar 会在响应收到 Set-Cookie 后保存 Cookie，并在后续请求中按 URL取回。若多个用户共用同一个 Jar，A 用户登录后写入的 session_id=A 与 B 用户的请求共享同一存储位置。此时业务代码看起来没有传错 userID，但服务端仍会按 Cookie 把请求识别为 A。

时间线往往是：先创建全局客户端，随后 A 登录；B 登录后覆盖同名 Cookie；A 的下一次请求又读到 B 的值。低并发时顺序碰巧正常，并不能证明设计安全。先排查 Jar 的创建位置和注入关系，比在每个请求前手动删除 Cookie 更可靠。

触发条件：把会话状态收进用户对象

下面的最小实现把 Jar、Client 和业务用户绑定在一起。cookiejar.New(nil) 创建内存 Jar；每次创建 UserSession 都会得到全新的存储空间。

package session

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

type UserSession struct {
    UserID string
    Client *http.Client
}

func NewUserSession(userID string) (*UserSession, error) {
    // 每个业务用户创建独立 Jar，避免登录 Cookie 互相可见。
    jar, err := cookiejar.New(nil)
    if err != nil {
        return nil, err
    }
    // Client 只持有当前用户的 Jar；Transport 可按连接池策略另行复用。
    return &UserSession{
        UserID: userID,
        Client: &http.Client{Jar: jar},
    }, nil
}

关键点不在于结构体名称，而在于“创建次数”：用户会话创建一次，Jar 创建一次。不要把 jar 提升成包级变量，也不要在工厂函数里缓存同一个 *http.Client 再返回给所有用户。

修复动作：所有请求都从会话入口发出

会话隔离完成后，还要避免调用方绕过 UserSession.Client。登录、读取个人资料和退出都使用同一个 Client，Cookie 才能沿着同一条用户链路流转。

func (s *UserSession) Login(loginURL string) error {
    // 登录响应中的 Set-Cookie 会自动写入当前用户的 Jar。
    req, err := http.NewRequest(http.MethodPost, loginURL, nil)
    if err != nil {
        return err
    }
    resp, err := s.Client.Do(req)
    if err != nil {
        return err
    }
    defer resp.Body.Close() // 及时释放响应体，保持连接复用。
    if resp.StatusCode != http.StatusNoContent && resp.StatusCode != http.StatusOK {
        return fmt.Errorf("login failed: %s", resp.Status)
    }
    return nil
}

func (s *UserSession) GetProfile(profileURL string) (*http.Response, error) {
    // 后续请求仍使用同一个 Client，由 Jar 自动带上当前用户 Cookie。
    req, err := http.NewRequest(http.MethodGet, profileURL, nil)
    if err != nil {
        return nil, err
    }
    return s.Client.Do(req)
}

示例只展示会话链路，生产代码还应按接口约定发送登录表单并限制响应体大小。若登录接口要求 Bearer Token，Token 也不能放在全局 Header 中，应放在用户会话对象或请求级 Header，避免把“Cookie隔离”误当成“所有认证状态都已隔离”。

防复发：并发、Transport 和生命周期要分开判断

标准库文档要求 CookieJar 实现可被多个 goroutine 并发使用，标准 cookiejar.Jar满足这一接口约束。但“一个 Jar 可并发安全”不等于“多个用户可以共享一个 Jar”：前者解决数据结构的竞态，后者改变了会话归属。

会话退出时，优先从会话管理器移除整个 UserSession，而不是试图把共享 Jar 清空。若需要持久化登录态，应为每个用户设计独立的安全存储和过期策略；内存 Jar 本身不会替你完成跨进程恢复、加密或注销同步。

常见问题

只为每个用户创建 Client，但复用同一个 Jar 可以吗？

不可以。Client 的指针不同并不能改变 Jar 的存储归属；只要 Jar 相同，Cookie 仍然会串。

每个用户一个 Client 会不会完全失去连接复用？

不必然。可让多个 Client 使用经过统一配置的 Transport，同时让每个 Client 持有自己的 Jar；连接池和 Cookie 存储是两个层次。

手动给请求加 Cookie 后还需要 Jar 吗？

如果全部认证状态都由请求级 Header 或 Cookie 明确管理，可以不用 Jar；但混用两种机制时要规定优先级，避免手动 Cookie 与 Jar 自动注入产生难以排查的覆盖。