登出必须严格匹配cookie参数并清理服务端状态：c.setcookie需设maxage=-1且path、domain、secure、httponly与登录时完全一致；同时删除redis黑名单、session或数据库token；登出接口须为post并校验csrf。
c.SetCookie 不能只清空值，必须配合过期时间与路径、域等参数一致才能真正删除 Cookie。
登出时 c.SetCookie 的参数必须严格匹配登录时设置的参数
Gin 本身不提供“删除 Cookie”的独立方法，所谓“删除”其实是覆盖写入一个已过期的同名 Cookie。浏览器收到后会按规则丢弃它——但前提是这个新 Cookie 的 Path、Domain、Secure、HttpOnly 必须和原来完全一致。否则旧 Cookie 仍留在客户端，下次请求还会带上。
- 登录时设置了
Path="/"、Domain="example.com"、Secure=true、HttpOnly=true - 登出时若漏掉
Domain或把Secure写成false，浏览器会认为这是另一个 Cookie，原 Token 依然有效 -
MaxAge必须设为-1（而非0），这是 Go 标准库对“立即过期”的约定
示例（正确）：
c.SetCookie("auth_token", "", -1, "/", "example.com", true, true)
登出逻辑要同步清理服务端状态
仅删 Cookie 不足以保障安全，尤其在使用 JWT 或 session 存储 token 的场景：
- 如果用 JWT 且做了黑名单（如 Redis 缓存失效列表），登出时必须调用
redis.Del("jwt_blacklist:" + token)类似操作 - 如果用基于服务端 session（如
gin-contrib/sessions+ redis），需调用session.Delete("user_id")或session.Options(sessions.Options{MaxAge: -1}) - 若 token 存在数据库（如
user_tokens表），应执行UPDATE user_tokens SET expired_at = NOW() WHERE token = ?
不清理服务端状态，攻击者拿到未过期的 Cookie 或 token 仍可重放请求。
登出接口必须是 POST，且校验 CSRF（如启用）
GET /logout 极易被诱导点击或图片 src 触发，造成非预期登出；更严重的是，如果没做 CSRF 防护，恶意网站可构造表单自动提交登出请求，影响用户体验甚至成为社工辅助手段。
- 路由定义用
router.POST("/logout", ...)，禁用 GET - 若项目启用了
gin-contrib/csrf中间件，确保登出 handler 能读取并验证X-CSRF-Token或表单字段_csrf - 前端登出按钮应通过
fetch(..., { method: "POST" })发起，附带 CSRF token
登出后重定向需谨慎处理 Referer 和 Location 头
直接 c.Redirect(http.StatusFound, "/login") 是常见做法，但要注意：
- 若用户从 /admin/dashboard 登出，重定向到 /login 后再跳回 /admin/dashboard，可能暴露内部路径
- 更稳妥的做法是清除 session 后返回 JSON，前端自行跳转：
c.JSON(200, gin.H{"code": 200, "msg": "登出成功"}) - 如果必须服务端跳转，避免拼接原始
Referer，防止开放重定向漏洞（如Redirect(302, c.Request.Referer())）
登出不是简单清 Cookie，关键在于客户端和服务端状态的一致性销毁。最容易被忽略的是参数匹配和 CSRF 防护——这两点一旦出错，登出就形同虚设。
