secure属性必须为true才能在https下生效，否则浏览器会忽略该cookie；开发环境http下需设false，生产https下必须设true，且须配合反向代理透传协议头验证。
Secure 属性必须为 true 才能在 HTTPS 下生效
如果你的线上服务走 HTTPS，但 SetCookie 的第 6 个参数（secure）传了 false，浏览器会直接忽略这个 Cookie —— 它根本不会被存储，后续请求也自然不会携带。
常见错误现象：本地 http://localhost 调试时一切正常，一上生产环境（https://example.com）就“读不到 Cookie”，不是代码问题，是 secure 没开。
- 开发环境用
http协议时，secure: false是唯一可行选项；强行设true会导致 Cookie 不写入 - 生产环境必须设
secure: true，否则 Cookie 无法通过 HTTPS 传输，等同于没设 - 不要依赖环境变量动态切换
secure值——Gin 不解析它，你得自己判断当前是否 HTTPS（比如检查c.Request.TLS != nil或反向代理头）
HttpOnly 设为 true 才能防 XSS 窃取
httpOnly 控制的是浏览器是否允许 JavaScript 通过 document.cookie 访问该 Cookie。设成 false 就等于把登录态明文暴露给前端脚本，XSS 攻击一旦发生，攻击者能立刻盗走 session token。
典型误用场景：为了“前端需要读某个配置”而把所有 Cookie 都设成 httpOnly: false。其实应该拆开——敏感字段（如 auth_token）严格设 true，非敏感字段（如 theme）才可放开。
-
httpOnly: true后，document.cookie里完全看不到该条目，fetch或XMLHttpRequest也无法通过响应头读取（它是响应头写入、请求头自动携带的单向机制） - Vue/React 应用里不要试图用 JS 读写
httpOnlyCookie，那是无效操作；状态同步应走 API 接口 - 如果用了前端身份校验（比如 JWT 存 localStorage），和
httpOnlyCookie 是两套逻辑，别混用
Domain 和 Path 配置错会导致跨子域失效
比如你的主站是 app.example.com，管理后台在 admin.example.com，想共享登录态，但 domain 写成 "app.example.com"，那 admin 子域就收不到 Cookie。
正确做法是统一设为 ".example.com"（开头带点），这样所有子域都可读写。但注意：localhost 不支持带点的 domain，开发时只能留空或写 "localhost"。
-
path设成"/"最安全，除非你明确要限制只在/api下发送（比如只给后端接口用） - Chrome 91+ 对
Domain校验更严：若不匹配当前域名，会静默丢弃 Cookie，不报错也不提示 - 设置
domain后，必须确保当前请求 Host 头与之匹配，Nginx 反向代理时注意透传 Host
MaxAge ≤ 0 的删除逻辑容易被当成“过期”而非“清除”
很多人以为把 maxAge 设为 0 就能删 Cookie，实际只有 -1 才触发浏览器立即删除行为。0 表示“不设 Max-Age 字段”，浏览器按自身策略处理（通常是会话级 Cookie，关浏览器就丢）。
更隐蔽的问题：用 SetCookie 删除时，value、path、domain 必须和当初设置时完全一致，否则旧 Cookie 不会被覆盖或清除。
- 删除操作本质是“下发一个 MaxAge=-1 的同名 Cookie”，所以务必复用原始的
path和domain - 如果原 Cookie 是
path: "/admin"，删除时用了path: "/"，那/admin下的旧 Cookie 依然存在 - 调试时用浏览器 DevTools 的 Application → Cookies 面板确认是否真被删掉，别只信返回状态
最常被忽略的其实是 domain 和 secure 的组合：HTTPS 站点配了 domain: "example.com" 但没加点，或者开发时硬编码 localhost 导致上线后全链路失效。这些细节不报错，但会让 Cookie 彻底失联。
