Go 问答：net/http Cookie.Expires 与 MaxAge 怎么配：删除、会话和持久化边界

登录接口明明返回了 Set-Cookie，用户关掉浏览器再打开却被当成未登录；另一个“退出登录”接口又只把 Expires 改成过去时间，部分客户端仍然保留 Cookie。排查这类问题时，重点不是把日期写得更早，而是分清 net/http.Cookie 的 Expires、MaxAge 和 Path 各自控制什么。

需要持久化登录态时明确设置正数 MaxAge，删除时使用相同的 Name、Path 和必要的 Domain，并设置负数 MaxAge；只想要会话 Cookie，则保持 MaxAge=0 且不依赖一个未来日期。

先看 Set-Cookie 到底表达了什么

net/http.Cookie 会把结构体字段序列化成响应头。MaxAge 为正数时，浏览器获得一个按秒计算的有效期；为负数时表示删除；为零时不输出 Max-Age。Expires 则是一个绝对时间字段，常用来补充客户端兼容性。

服务端可以直接用 http.SetCookie 写出响应头。下面的 loginCookie 把长期登录态和作用域固定在一起，后续退出时必须复用同一组关键字段。

func loginCookie(value string) *http.Cookie {
    return &http.Cookie{
        Name:     "session_id",
        Value:    value,
        Path:     "/",
        MaxAge:   7 * 24 * 60 * 60,
        Expires:  time.Now().Add(7 * 24 * time.Hour),
        HttpOnly: true,
        Secure:   true,
        SameSite: http.SameSiteLaxMode,
    }
}

func login(w http.ResponseWriter, r *http.Request) {
    http.SetCookie(w, loginCookie("signed-session"))
    w.WriteHeader(http.StatusNoContent)
}

这条路径里，SetCookie 接收 loginCookie，再把 MaxAge 和 Expires 写到响应头。不要只在服务端日志里打印结构体就宣布成功，浏览器开发者工具的 Network 面板才是核对实际 Set-Cookie 的入口。

会话 Cookie 和持久化 Cookie 的差别

如果 MaxAge=0，并且没有提供有效的 Expires，它通常表现为会话 Cookie：客户端决定在会话结束时清理。需要“七天内重新打开仍保持登录”时，使用正数 MaxAge 更直接，Expires 可以同步给出一个绝对截止时间。

这里有个容易忽略的细节：客户端会根据自己的 Cookie 规则处理有效期，服务端不能从下一次请求推断用户是否真的把 Cookie 写入磁盘。排查时把响应头、浏览器存储区和下一次请求的 Cookie 头分成三段核对。

退出登录为什么经常删不干净

删除 Cookie 不是把值设为空就结束。服务端要发送一条同名的删除 Cookie，并尽量复用创建时的 Path；如果创建时设置过 Domain，删除时也要保持一致。MaxAge=-1 是 Go 代码里最清晰的删除意图。

func logout(w http.ResponseWriter, r *http.Request) {
    http.SetCookie(w, &http.Cookie{
        Name:     "session_id",
        Value:    "",
        Path:     "/",
        MaxAge:   -1,
        Expires:  time.Unix(1, 0),
        HttpOnly: true,
        Secure:   true,
        SameSite: http.SameSiteLaxMode,
    })
    w.WriteHeader(http.StatusNoContent)
}

如果创建 Cookie 用的是 Path: "/account"，退出响应却使用 Path: "/"，浏览器可能同时留下两条同名 Cookie。此时后端看到的值看起来像“退出失败”，其实是作用域没有对上。

用 Request.Cookie 分辨有效期误判

读取请求时，r.Cookie 只告诉服务端客户端这次请求带来了什么，不会把原始 Expires 和 Max-Age 再带回来。下面只负责取得 session_id，会话是否有效仍应由服务端查会话存储和过期时间。

func currentSession(r *http.Request) (string, error) {
    cookie, err := r.Cookie("session_id")
    if err != nil {
        return "", err
    }
    if cookie.Value == "" {
        return "", http.ErrNoCookie
    }
    return cookie.Value, nil
}

Request.Cookie 成功只说明请求里有这个名称和值，不能证明它还对应数据库中的有效会话。登录接口写入 SetCookie、后续请求读取 Request.Cookie，中间还隔着浏览器的存储和发送规则，这就是完整调用链。

三个边界别混在一起

只设置 Expires，不设置 MaxAge

这可能满足部分客户端的持久化需求，但团队很难从 Go 代码一眼看出“有效多少秒”。如果业务以秒为单位管理会话期限，建议把正数 MaxAge 写明，并让 Expires 与它指向同一个截止时间。

删除时只改 Value

空值不等于删除。用负数 MaxAge 发送删除意图，并核对 Path、Domain 是否与创建 Cookie 一致。

把 Cookie 有效期当成服务端会话有效期

客户端 Cookie 只是凭据容器。服务端仍要检查 session 存储中的过期时间、吊销状态和用户状态，不能因为 MaxAge 还没到期就放过服务端校验。

上线前的核对顺序

1. 登录响应：在 Network 面板确认 Set-Cookie 包含预期的 Name、Path、Max-Age 和 Expires。
2. 重新打开浏览器：确认请求的 Cookie 头仍包含 session_id，并在服务端用 Request.Cookie 读到它。
3. 退出响应：确认删除 Cookie 的 Path 与创建时一致，且 Max-Age 表达删除。
4. 服务端验收：即使客户端还带着值，已过期或已吊销的 session 也必须被拒绝。

相关问题

MaxAge=0 是立即删除吗？

不是。对 Go 的 Cookie 来说，MaxAge=0 表示不指定 Max-Age；明确删除使用负数 MaxAge。

Expires 和 MaxAge 同时存在时怎么维护？

把它们指向同一个业务截止时间：MaxAge 表达秒数，Expires 表达绝对时间，避免一边改了七天、一边仍是三天。

为什么退出后请求仍带着旧 Cookie？

优先查 Path 和 Domain 是否匹配创建值，再看是否存在同名的另一条 Cookie。最后才检查浏览器是否真的收到了删除响应。

小结

Expires、MaxAge 和 Path 解决的是不同问题：前两个定义有效期表达，后一个决定哪一条 Cookie 会被覆盖或删除。登录时把有效期写清，退出时复用作用域，服务端再独立检查 session 状态，Cookie 生命周期就不会只靠猜。