Go http.Cookie 怎样定位资源未释放

Go http.Cookie 本身是描述 Cookie 的普通数据结构，没有 Close，也不直接持有需要关闭的网络连接。怀疑“Cookie 导致资源未释放”时，应分别检查 HTTP 响应体是否关闭、CookieJar 是否被长期持有，以及业务缓存是否保留了 Cookie 或响应对象。不要给 Cookie 寻找不存在的释放方法。

官方地址：https://pkg.go.dev/net/http

先分清需要释放的对象

设想一个定时请求服务：每次取回响应 Cookie，同时把完整响应存进历史列表。运行久了内存上涨，不能仅凭处理了 Cookie 就认定标准库泄漏。这是假设排障场景，不是实测事故。我的判断顺序是先找资源所有者，再看引用为什么还存在。

Response.Body 是需要管理关闭的流；Cookie 是解析后的字段；Jar 是保存后续请求所需 Cookie 的存储；Transport 维护连接池。它们生命周期不同。

最小配方：一次请求在一个函数内收尾

package cookiemeta

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

// CookieNames 只提取名称，不记录可能含凭据的 Cookie 值。
func CookieNames(ctx context.Context, client *http.Client, address string) ([]string, error) {
    req, err := http.NewRequestWithContext(ctx, http.MethodGet, address, nil)
    if err != nil {
        return nil, fmt.Errorf("build request: %w", err)
    }
    resp, err := client.Do(req)
    if err != nil {
        return nil, fmt.Errorf("send request: %w", err)
    }

    names := make([]string, 0)
    for _, cookie := range resp.Cookies() {
        names = append(names, cookie.Name)
    }
    // 此任务不读取正文，显式关闭；不保证底层连接可被复用。
    if err := resp.Body.Close(); err != nil {
        return nil, fmt.Errorf("close response body: %w", err)
    }
    return names, nil
}

示例提取的是最终响应里的 Set-Cookie 名称，不包括自动重定向过程的全部历史 Cookie。它不判断 HTTP 状态码是否符合业务要求：Do 返回 nil 错误不表示业务成功。调用方应使用有适当超时的客户端或请求上下文。

若循环执行，把每次请求封装在类似的小函数中，有助于避免把 defer 堆到整个长循环结束才运行。需要读取正文时，必须覆盖读取失败等所有返回分支，并关闭 Body。为了复用连接而读取到 EOF，只适合正文大小和时间预算受控的场景；不要无上限丢弃不可信的大正文。

Jar 和业务容器为什么仍会保留数据

客户端配置 Jar 时，Jar 保存符合规则的 Cookie，用于后续请求。这个跨请求状态本来就应该比一次响应活得更久。不能把“请求已完成但 Cookie 仍在 Jar 中”直接当成泄漏。标准 CookieJar 接口也没有统一的 Close 或枚举全部条目的方法。

业务如果为每个任务建立客户端和 Jar，再把它们放进永不淘汰的 map，引用链仍然存在。应定义任务完成后的容器移除、缓存容量与会话隔离规则。把局部 cookie 变量设为 nil，不能移除其他容器或闭包里的引用，也不能保证进程常驻内存立即下降。

删除 Cookie 不等于删除服务端会话

向客户端发出过期 Cookie，是改变客户端后续携带状态的协议操作；撤销服务端会话则由应用的会话存储负责。Cookie 的过期时间也不是 Go 对象的析构时间。即使浏览器不再发送某个标识，服务端数据库或缓存里的会话记录仍需按应用策略到期或撤销。

需要删除指定 Cookie 时，还必须考虑对应的名称、路径及域范围，不能用一次不匹配的覆盖就推断删除已完成。本文不提供通用退出登录片段，因为应用的会话存储、身份撤销和 Cookie 范围需要一起设计。

按症状找所有者

排查记录建议只保存数量、归属和生命周期，避免输出完整 Cookie 值、会话标识或认证头。关闭空闲连接不是清空 Jar 的方法，手工触发 GC 也不能替代删除不再需要的业务引用。

相关问题

Response.Cookies 返回后必须逐个释放吗？不需要逐个关闭；普通对象按可达性由垃圾回收管理。

只关 Body 能保证连接复用吗？不能。正文是否读到 EOF、协议和连接状态都会影响复用；示例选择及时关闭而不承诺复用。

Jar 为空是否说明内存立即归还操作系统？不能。业务引用、运行时内存管理和系统观测指标需要分别理解。

依据：http.Cookie 与 Response 文档、cookiejar 文档。示例未执行，不提供虚构资源曲线。