Cookie生命周期由MaxAge和Expires共同决定：maxAge>0表示响应发出后多少秒过期，=0为会话级Cookie，<0立即失效；Gin通过Max-Age头控制，但旧浏览器依赖Expires，故需确保服务器时间准确以保障兼容性。
Cookie生命周期由MaxAge和Expires共同决定
在Gin中，c.SetCookie() 设置的Cookie实际生效周期不只看传入的 maxAge 参数，还要看浏览器是否同时收到 Expires 字段。Gin内部会把 maxAge 转为 Max-Age 响应头，但如果 maxAge 为正数且未显式设置 Expires，部分旧版浏览器（如IE）可能忽略 Max-Age，只认 Expires —— 这时生命周期就不可靠。
真正可控的方式是：用 maxAge 控制秒级时效，同时避免手动拼 Expires 字符串（Gin不提供该参数接口，也不建议自己写响应头覆盖）；若需兼容极老环境，应统一用正整数 maxAge 并确保服务器时间准确。
-
maxAge > 0：表示从响应发出时刻起，多少秒后过期（例如3600是1小时） -
maxAge == 0：等效于会话期 Cookie，浏览器关闭即失效（但注意会话恢复功能可能保留） maxAge ：立即过期，用于删除 Cookie（不是清空值，而是让浏览器丢弃）
删除Cookie必须匹配原始路径和域名
调用 c.SetCookie("name", "", -1, path, domain, secure, httponly) 才能可靠删除，其中 path 和 domain 必须与当初设置时完全一致，否则浏览器认为是另一个 Cookie，不会覆盖或清除旧的。
常见错误是登出时用 "/" 和 ""（空域名）去删一个当初设在 "example.com" 上的 Cookie —— 它依然留在客户端，下次请求还会发过来。
- 本地开发时，
domain设为"localhost"或留空（""），上线后必须设为实际域名（如"example.com"） -
path默认是"/"，但如果当初设为"/admin"，删除时也得传"/admin" -
secure和httponly标志也要保持一致，否则某些浏览器拒绝覆盖
HttpOnly + Secure 组合影响生命周期感知
当 httponly=true 时，前端 JavaScript 无法读取或修改该 Cookie，也就无法主动清理；而 secure=true 意味着 HTTP 协议下该 Cookie 根本不会被发送——这会让开发者误以为“Cookie 没了”，其实是协议层拦截了。
调试时如果发现 Cookie 突然不出现，先确认当前页面是否 HTTPS、是否用了 secure=true、以及浏览器地址栏有没有锁图标。HTTP 页面即使设置了 secure=true，Cookie 也不会被携带，但也不会报错，容易当成生命周期问题排查。
- 开发阶段建议
secure=false，上线再切 true -
httponly=true是安全必需，但意味着所有 Cookie 生命周期管理都只能靠服务端控制 - 浏览器 DevTools 的 Application → Cookies 面板可查看当前域下所有 Cookie 及其
Expires、Max-Age、Secure、HttpOnly状态
SameSite 属性不改变生命周期，但影响发送时机
SameSite（Gin 中第7个参数）控制的是 Cookie 是否随跨站请求发送，和存多久无关。但它会间接导致“看似消失”：比如设了 SameSite=Lax（Gin 默认 true 对应 Lax），用户从第三方网站跳转过来时，Cookie 不会被带上，服务端就读不到，误以为过期或丢失。
这不是生命周期问题，而是上下文匹配失败。若需支持嵌入 iframe 或 OAuth 回调，得显式设 SameSite=None，但此时 secure 必须为 true，否则现代浏览器直接拒收。
-
SameSite=Strict：仅同站顶级导航才发送（最严） -
SameSite=Lax：GET 类导航（如链接跳转）会发，POST 表单提交不发（默认行为） -
SameSite=None：所有跨站请求都发，但强制要求secure=true
