cookie设为secure=true时仅https生效，http下浏览器静默丢弃；localhost开发时需启用https并避免domain设为localhost，且删除时secure属性必须与设置时一致。
必须设 secure 为 true，且只在 HTTPS 环境下生效，否则浏览器直接忽略该 Cookie。
为什么 secure 设为 true 却没生效
常见现象是开发时用 http://localhost:8080 访问，但设置了 c.SetCookie("token", "xxx", 3600, "/", "localhost", true, true)，结果浏览器根本不存这个 Cookie。
-
secure = true意味着“仅限 HTTPS 传输”，HTTP 协议下浏览器会静默丢弃该 Cookie，不报错也不提示 - 本地调试时若想测试
secure行为，必须启用 HTTPS（例如用mkcert生成本地证书 +router.RunTLS(":443", "cert.pem", "key.pem")） - 域名字段
domain若填"localhost"，部分浏览器（如新版 Chrome）会拒绝接受secure+localhost组合，建议开发时先设为""或省略（Gin 会自动推导）
httpOnly 能防什么、不能防什么
httpOnly = true 是防止 XSS 攻击的关键一环，但它只限制 JavaScript 读取，不影响其他层面的泄露风险。
- 它让
document.cookie读不到该 Cookie，XMLHttpRequest和fetch也无法通过 JS 获取其值 - 但它不阻止网络层窃听：如果传输未加密（即没配
secure），中间人仍可截获 Cookie 字段 - 它也不影响服务端日志：若错误地把 Cookie 值打到日志里，依然可能泄露
- 注意：Gin 的
c.Cookie()仍能正常读取 ——httpOnly只约束客户端 JS，不限制服务端逻辑
生产环境必须匹配的三组参数
Cookie 能否被正确发送，取决于客户端请求 URL 与 Cookie 元数据的严格匹配。任意一项不一致，浏览器就不带它。
-
协议：请求必须是 HTTPS，否则
secureCookie 不会随请求发出 -
域名：请求域名必须符合
domain设置（如设"example.com"，则api.example.com和www.example.com都匹配；但"sub.example.com"不匹配"example.com"，除非显式设为".example.com"） -
路径：请求路径必须以
path开头（如设"/admin"，则/admin/user匹配，但/api不匹配）
删除 secure Cookie 的陷阱
用 c.SetCookie(name, "", -1, path, domain, secure, httpOnly) 删除时，secure 和 httpOnly 必须与原始设置完全一致，否则旧 Cookie 可能残留。
- 如果原 Cookie 是
c.SetCookie("auth", "x", 3600, "/", "example.com", true, true)，删除时也必须传true, true - 尤其注意：开发环境删 Cookie 时若漏掉
secure: true，而生产环境它是true，会导致线上 Cookie 删不干净 - 更稳妥的做法是：登出时同时发两条
Set-Cookie头，一条secure=true，一条secure=false（仅用于兼容过渡），但生产环境应统一策略
真正容易被忽略的不是怎么设，而是怎么验证——用浏览器开发者工具的 Application → Cookies 面板看 “Secure” 和 “HttpOnly” 标志是否打钩，再切到 Network → 请求头 → Cookie 确认它是否真的出现在请求中。这两步缺一不可。
