go 中使用 `http.client` 发送请求时，即使配置了 `cookiejar`，`resp.cookies()` 仍返回空数组——这是因为 `cookies()` 方法仅返回**响应头中显式 set-cookie 字段解析出的 cookie（即服务端直接设置的 cookie）**，而非 `cookiejar` 自动管理的已存储 cookie；如需获取 jar 中已保存的 cookie，应调用 `jar.cookies()` 并传入对应 url。
在 Go 的 net/http 包中，http.Response.Cookies() 方法的作用常被误解：它*仅解析当前响应头中的 Set-Cookie 字段并返回其对应的 `http.Cookie切片**，并不读取或反映cookiejar中已持久化存储的 Cookie 状态。因此，即使cookiejar成功接收并保存了服务端下发的 Cookie，resp.Cookies()依然可能为空——尤其当响应本身未携带Set-Cookie（例如重定向后的最终响应、或服务端仅通过Set-Cookie` 设置但后续响应不再重复下发）时。
✅ 正确做法是：*若需获取客户端当前“已持有”的所有 Cookie（即 jar 中为该域名缓存的 Cookie），应主动调用 cookiejar.Cookies() 方法，并传入原始请求 URL（必须是 `url.URL` 类型）**：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
jar, err := cookiejar.New(&cookiejar.Options{
PublicSuffixList: publicsuffix.List, // 推荐设置，增强兼容性（需导入 golang.org/x/net/publicsuffix）
})
if err != nil {
log.Fatal("failed to create cookie jar:", err)
}
client := &http.Client{Jar: jar}
resp, err := client.Get("https://example.com/login")
if err != nil {
log.Fatal("request failed:", err)
}
defer resp.Body.Close()
// ✅ 错误：resp.Cookies() 仅返回本响应头中的 Set-Cookie（可能为空）
// fmt.Println("Resp.Cookies():", resp.Cookies())
// ✅ 正确：从 jar 中查询该域名下已存储的所有 Cookie
u, _ := url.Parse("https://example.com/login")
cookies := jar.Cookies(u)
fmt.Println("Jar cookies for example.com:", cookies)⚠️ 注意事项：
- cookiejar.Cookies(u) 要求传入的 *url.URL 必须包含有效的 Scheme 和 Host，否则返回空切片；
- cookiejar 默认仅对符合 Public Suffix List 规则的域名生效（如 example.com），若测试使用 localhost 或自定义域名，建议启用 Options.Strict 或配合 publicsuffix.List（推荐）以避免因域名校验失败导致 Cookie 被丢弃；
- http.Client.Jar 为 nil 时，client.Get() 不会自动处理 Set-Cookie，也不会发送 Cookie —— 所以务必确保 Jar 已正确初始化并赋值；
- resp.Cookies() 在调试时仍有价值：可用于验证服务端是否在本次响应中明确设置了新 Cookie（例如登录成功后首次返回的 Set-Cookie），但它不是“当前会话 Cookie 的快照”。
? 总结：resp.Cookies() ≠ 当前会话 Cookie；它是“本次响应头的 Cookie 快照”。要获取 Go HTTP 客户端当前实际持有的 Cookie，请始终使用 jar.Cookies(reqURL)。这是理解 Go HTTP Cookie 管理机制的关键分水岭。
