Go 标准库的 net/http/cookiejar 不提供直接遍历或导出所有 Cookie 的接口，其设计为仅支持按特定域名（需为有效 URL）查询匹配的 Cookie，无法获取全局或通配符范围的完整内容。

go 标准库的 `net/http/cookiejar` 不提供直接遍历或导出所有 cookie 的接口，其设计为仅支持按特定域名（需为有效 url）查询匹配的 cookie，无法获取全局或通配符范围的完整内容。

在 Go 中，http.CookieJar 是一个接口，而标准库实现的 *cookiejar.Jar 是私有结构体，其内部存储（如 entries 字段）未暴露给外部使用。这意味着你无法直接访问 jar 中所有 Cookie 的完整集合，也不能像调试浏览器 DevTools 那样“列出全部已存 Cookie”。

你当前代码中的问题在于：

• client.Jar.Cookies(u) 要求 u 是一个有效的、带 scheme 的 URL（如 https://google.com），而你传入的是 ".google.com"（纯域名字符串），url.Parse(".google.com") 返回 nil，导致 Cookies() 返回空切片；
• 即使传入合法 URL（如 https://accounts.google.com），Cookies() 也只返回该 URL 对应路径下有效的、未过期的 Cookie，且不包含其他域名（如 .youtube.com 或 google.com 的子域）的 Cookie。

✅ 正确用法示例（按目标域名查询）：

u, err := url.Parse("https://accounts.google.com")
if err != nil {
    log.Fatal(err)
}
cookies := client.Jar.Cookies(u)
fmt.Printf("Cookies for %s: %+v\n", u.Host, cookies)

⚠️ 注意事项：

NotebookLM CLI Cookies

使用 nlm CLI 检索并回答已上传至 NotebookLM 的文档问题。适用于用户需要查找信息、总结来源或查询特定笔记本时。

下载

• cookiejar.Jar 默认使用 RFC 6265 兼容策略，自动处理 Domain、Path、Secure、HttpOnly 和过期逻辑；
• Cookie 仅在请求/响应流程中由 http.Client 自动注入和保存，Jar 本身不提供 All()、Dump() 或 Export() 方法；
• 若需调试或审计 Cookie，推荐方案是：
  1. 拦截 HTTP 流量：使用 httputil.DumpResponse 查看响应头中的 Set-Cookie；
  2. 自定义 CookieJar 实现：嵌入标准 *cookiejar.Jar 并记录每次 SetCookies 调用（需实现 SetCookies 和 Cookies 方法）；
  3. 使用第三方库：如 github.com/microcosm-cc/bluemonday（非 Cookie 相关）不适用；更现实的是自行封装日志型 Jar（见下方最小示例）。

? 自定义可观察的 CookieJar（轻量实现）：

type LoggingJar struct {
    *cookiejar.Jar
    mu       sync.RWMutex
    all      []*http.Cookie // 仅用于调试，不参与实际逻辑
}

func (j *LoggingJar) SetCookies(u *url.URL, cookies []*http.Cookie) {
    j.mu.Lock()
    j.all = append(j.all, cookies...)
    j.mu.Unlock()
    j.Jar.SetCookies(u, cookies) // 委托给原生 Jar
}

func (j *LoggingJar) AllCookies() []*http.Cookie {
    j.mu.RLock()
    defer j.mu.RUnlock()
    return append([]*http.Cookie(nil), j.all...) // 安全拷贝
}

? 总结：标准 cookiejar 是有意设计为“黑盒”——它保障安全性与语义正确性，但牺牲了可观测性。生产环境应依赖协议行为（如检查 Set-Cookie 头），调试阶段可通过自定义 Jar 或 HTTP 抓包辅助分析，而非试图反向读取内部状态。