Gin测试中需手动构造Cookie请求头，如req.Header.Set("Cookie", "auth_token=abc123; theme=dark")，不能依赖httptest自动携带；验证Cookie应检查w.Header().Get("Set-Cookie")而非响应体，且跨请求状态需显式提取并重设Cookie头。
直接用 httptest.NewRequest + httptest.NewRecorder 模拟带 Cookie 的请求，就能测状态保留——但必须手动把 Cookie 写进请求头，Gin 不会自动从响应里提取再塞回下一次请求。
怎么构造带 Cookie 的测试请求
浏览器发请求时，是把 Cookie 作为 Cookie 请求头发送的，格式为 "name1=value1; name2=value2"。测试时得自己拼，不能依赖上一个响应自动携带。
- 别写
req.AddCookie(&http.Cookie{...})：它只在http.Client场景生效，httptest.NewRequest不解析这个，得手动设头 - 正确做法是拼字符串后调
req.Header.Set("Cookie", "auth_token=abc123; theme=dark") - 值要 URL 编码？不用——
c.SetCookie()已编码，c.Cookie()已解码，测试时传原始值即可（如"abc123"） - 多个 Cookie 用分号+空格分隔，顺序无关，但名字不能重复，否则后一个覆盖前一个
如何验证 Cookie 是否被正确设置
检查响应头里的 Set-Cookie 字段，而不是看 w.Body.String() ——后者是响应体，和 Cookie 无关。
- 用
w.Header().Get("Set-Cookie")获取原始头值，它返回类似"auth_token=abc123; Path=/; Domain=localhost; Max-Age=3600; HttpOnly; Secure"的字符串 - 注意：
Set-Cookie可能出现多次（比如设了两个 Cookie），此时要用w.Header()["Set-Cookie"]拿切片 - 断言时别用
strings.Contains粗暴匹配——Max-Age值可能因时间漂移微变，建议用正则或拆分键值对校验关键字段（如Path、HttpOnly、Secure） - 如果 handler 调了
c.SetCookie("a", "b", -1, ...)，响应头里必须出现Max-Age=0或Expires=...（取决于 Go 版本），这是删除 Cookie 的信号
测试跨请求的 Cookie 状态保留
单个测试函数内无法自动“保留” Cookie，必须显式传递——这是最容易误以为“状态没保存”的地方。
- 第一次请求（如登录）后，从
w.Header()["Set-Cookie"]提取值，解析出auth_token=xxx部分 - 第二次请求（如访问受保护接口）前，用提取的值构造新的
Cookie头：req2.Header.Set("Cookie", "auth_token=xxx") - 别漏掉域名和路径匹配：若原
SetCookie设了path="/admin"，但第二次请求 URL 是/user，浏览器（和你的测试）不会发送该 Cookie - 中间件里用
c.Cookie("x")读不到？先确认请求头里真有Cookie: x=...，再查 handler 是否在中间件执行前就 abort 了
为什么测试中常出现 Cookie 读不到或设不成功
问题往往不在 Gin 逻辑本身，而在测试构造细节或参数语义误解。
-
maxAge = 0不代表“永不过期”，而是忽略Max-Age字段，退化为会话级 Cookie（关浏览器即丢）；想持久化必须传正数 -
domain填"localhost:8080"会失败——domain 不接受端口，开发填"localhost"，生产填"example.com" -
secure = true但测试用 HTTP 协议（http://）？浏览器直接拒发，测试里必须设false或改用 HTTPS 测试服务器（麻烦且不必要） - 用
c.ShouldBindJSON之类方法时，如果请求体是 JSON 但忘了设Content-Type: application/json，Gin 会静默跳过绑定，导致后续依赖 body 的逻辑出错，看起来像 Cookie 丢了
真正难的不是写几行测试代码，而是意识到 Cookie 的生命周期由浏览器规则驱动，而测试环境是手工模拟的——每一步都得对齐真实行为，少一个分号、错一个 domain，状态就断了。
