SetCookie传空值无法删除Cookie，必须显式设置MaxAge=0、Expires为过去时间，并完全匹配原Cookie的Name、Domain、Path、Secure、HttpOnly、SameSite等所有属性。
为什么 SetCookie 传空值或过期时间无法真正“删除” Cookie？
浏览器对 Cookie 的“删除”只是约定俗成：服务端发一个同名、MaxAge=0 或 Expires 设为过去时间的响应头，浏览器才会丢弃它。但如果你只写 c.SetCookie("token", "", ...) 而没设过期，浏览器会当作“会话 Cookie”保留，下次请求仍带上。更隐蔽的问题是：若原 Cookie 带了 Secure、HttpOnly 或 SameSite 属性，新响应必须**完全一致地重复这些属性**，否则旧 Cookie 不会被覆盖或清除。
用 c.SetCookie 安全清空 Cookie 的 4 个必要参数
必须显式覆盖所有原始设置项，哪怕你记不清当初怎么设的，也要按当前部署环境补全。常见遗漏点：
-
Name和Domain必须与原 Cookie 严格一致（注意子域名通配符，比如原设Domain=".example.com"，这里也得写） -
MaxAge设为0，同时Expires设为time.Unix(0, 0).UTC()（双保险，兼容老客户端） -
Path不能省略，默认是 "/"，但如果原 Cookie 是Path="/api"，这里不写就清不掉 -
Secure、HttpOnly、SameSite必须和原值相同；开发环境Secure=false，生产环境通常为true
示例（假设原 Cookie 是 HTTPS 下设的）：
c.SetCookie(&http.Cookie{
Name: "session_id",
Value: "",
Path: "/",
Domain: ".example.com",
MaxAge: 0,
Expires: time.Unix(0, 0).UTC(),
Secure: true,
HttpOnly: true,
SameSite: http.SameSiteLaxMode,
})
重置多个 Cookie 时，别依赖循环调用 SetCookie
每次调用 c.SetCookie 都会写一条 Set-Cookie 响应头，但 HTTP/1.1 对响应头数量无硬限制，问题出在客户端解析上：某些旧版 iOS Safari 或嵌入式 WebView 会截断多余头。更稳妥的做法是分批清理，或优先清关键 Cookie（如 auth token），再通过前端跳转触发完整登出流程。如果必须批量操作：
- 确保每个
SetCookie调用都带完整属性，不要复用同一个http.Cookie实例改Name后反复传 - 避免在中间件里无条件清所有 Cookie——比如健康检查接口不该意外清登录态
- 测试时用
curl -v或浏览器 DevTools 的 Network → Response Headers 确认每条Set-Cookie都存在且参数正确
前端配合清 Cookie 的边界情况
服务端清完不代表前端立刻失效。如果前端 JS 里缓存了 document.cookie 字符串或 token 值，后续请求可能仍携带旧凭证。尤其要注意：
- 单页应用（SPA）中，清 Cookie 后未重载页面，
fetch请求仍可能用旧 session 发起 - 若用了
credentials: "include"，且后端返回 200 但没清干净，前端不会自动感知失败 - 推荐组合动作：服务端清 Cookie + 返回
{"logged_out": true}+ 前端跳转到登录页（而非仅清本地 storage）
真正的“重置”从来不是单点操作，而是服务端响应、客户端行为、网络协议三者对齐的结果。漏掉任意一环，用户就可能看到“已退出”提示，却还能点开个人中心页面。
