Go http.Cookie RawExpires 怎样保留原始过期时间文本

如果你从 Set-Cookie 头解析出一个 http.Cookie，又想保留服务端原来写下的过期时间文本，应该读取 RawExpires；如果要做过期判断、排序或再次发送，则应该使用 Expires。两者来自同一个 Expires=... 属性，但用途不同。

最容易踩坑的地方是：RawExpires 只面向读取，Cookie.String() 重新序列化时不会把它原样写回，而是根据 Expires time.Time 生成规范化的日期。如果原始日期无法被 Go 识别，RawExpires 仍可能保留文本，但 Expires 会是零值。

先分清 RawExpires 与 Expires

http.Cookie 的字段定义已经给出了关键线索：Expires 是 time.Time，而 RawExpires 的注释是“for reading cookies only”。因此可以把它们理解为一对“原文”和“语义值”：

• RawExpires：读取 Set-Cookie 时保存的过期时间文本，适合日志、审计和排查上游格式。
• Expires：解析成功后的时间值，适合与 time.Now() 比较、计算剩余时间或排序。

这不是两个可以互相替代的缓存字段。把原始字符串当成业务时间使用，会让格式、时区和解析失败处理散落在业务代码里；只保留 Expires，又会丢掉上游实际发送的文本。

从 Set-Cookie 解析并读取两个字段

服务端响应里的属性通常类似下面这样。这个示例只演示读取，不代表在本机发送了真实请求：

package main

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

func main() {
    line := "session=abc123; Expires=Wed, 21 Oct 2026 07:28:00 GMT; Path=/"

    cookie, err := http.ParseSetCookie(line)
    if err != nil {
        // 语法错误直接结束；RawExpires 只会出现在解析出 Cookie 后。
        fmt.Println("解析失败:", err)
        return
    }

    fmt.Println("原始文本:", cookie.RawExpires)
    fmt.Println("规范时间:", cookie.Expires.Format(time.RFC3339))
    fmt.Println("距离现在:", time.Until(cookie.Expires))
}

这里的职责分工很清楚：RawExpires 用于展示服务端写入的文本，Expires 用于时间运算。Go 的解析实现会先把 Expires 属性值写入 RawExpires，再尝试按支持的格式解析；成功后把时间转换为 UTC 保存到 Expires。

解析失败时，为什么 RawExpires 可能有值

在排查兼容性问题时，下面这个状态很有价值：RawExpires 不为空，但 Expires.IsZero() 为真。它表示 Go 已经识别到这是 Expires 属性，却没有把属性值解析成可用的 time.Time。

func describeExpiry(cookie *http.Cookie) string {
    if cookie == nil {
        // nil Cookie 没有字段可读，先给调用方一个明确结果。
        return "Cookie 不存在"
    }
    if cookie.RawExpires == "" {
        // 没有 Expires 属性，不能把零值误解为已过期。
        return "没有 Expires 属性"
    }
    if cookie.Expires.IsZero() {
        // 保留原文便于定位上游格式，但不要拿零值做过期判断。
        return "Expires 无法解析，原文=" + cookie.RawExpires
    }
    // 只有解析成功后，Expires 才适合进入时间比较或排序。
    return "Expires=" + cookie.Expires.UTC().Format(time.RFC3339)
}

因此，业务代码不要只写 if cookie.Expires.Before(time.Now())。更稳妥的判断顺序是：先区分没有属性、属性存在但解析失败、解析成功且已经过期这三种情况。尤其不要把零值直接当成“已经过期”，否则上游格式问题会被误报成正常的过期 Cookie。

解析后的时间通常会以 UTC 保存，这是为了让不同机器上的时间比较保持一致；如果要显示给用户，再在展示层转换到目标时区，不要为了显示格式去修改 RawExpires。

重新序列化时不要依赖 RawExpires

如果要把 Cookie 放回响应头，调用 cookie.String() 或 http.SetCookie。这条路径使用的是 Expires，并按照 Go 的 Cookie 时间格式重新生成文本；RawExpires 不会作为原文回放。

func outgoingCookie(input *http.Cookie) string {
    if input == nil {
        // 空指针不能生成有效的 Set-Cookie 文本。
        return ""
    }
    if input.Expires.IsZero() && input.RawExpires != "" {
        // 原始时间无法解析时，不把不确定的日期继续转发为业务有效期。
        return ""
    }
    // String 会根据 Expires 等结构化字段输出规范化属性。
    return input.String()
}

这意味着“读取后原样转发”与“解析后重新生成”是两个不同需求：

把读取、审计和发送职责分开

在反向代理、缓存层或调试中间件里，建议把 Cookie 处理拆成三个明确动作：

1. 解析阶段保留 RawExpires，把它和 Cookie 名称、来源响应关联起来，便于定位上游差异。
2. 业务阶段只使用非零的 Expires 做时间判断；如果它是零值，就走“格式不可用”的分支。
3. 发送阶段根据结构化字段重新生成 Cookie，并在转发前决定是否需要丢弃无法解析的过期属性。

还要注意，Cookie 的 Max-Age 与 Expires 是不同属性。本文只讨论 RawExpires 保存的过期文本；如果业务同时处理 Max-Age，应按协议和客户端策略单独判断优先级，不要用 RawExpires 推断 Max-Age。

常见问题

RawExpires 能不能手动赋值后让 String 原样输出？

不应该这样设计。RawExpires 的定位是读取字段，重新序列化依赖 Expires。如果需要保留原样文本，应把原始头单独记录，而不是把 RawExpires 当成发送字段。

RawExpires 为空是不是代表 Cookie 永不过期？

不一定。它可能表示没有 Expires 属性，也可能是当前 Cookie 来源没有经过 Set-Cookie 的过期属性解析。还要结合 MaxAge 和具体协议语义判断。

Expires 是零值时可以直接当作已过期吗？

不建议。零值也可能意味着没有 Expires 属性，或原始值无法解析。先检查 RawExpires 是否为空，再决定是“无过期时间”还是“过期字段格式异常”。

记住一句话即可：RawExpires 用来回答“上游原文写了什么”，Expires 用来回答“这个时间值怎么参与程序判断”。读取时保留两者，业务判断使用结构化时间，重新发送则让 Cookie.String() 根据 Expires 生成规范格式。