Secure和HttpOnly必须设为true，否则易遭中间人劫持或XSS窃取；Domain、Path应最小化作用域；MaxAge设-1才能彻底删除Cookie，设0无效。
SetCookie 的参数组合不对，Session 劫持风险就藏在默认值里。
Secure 参数必须为 true（HTTPS 环境下）
如果部署在 HTTPS 域名下但 secure 设为 false，浏览器仍可能通过 HTTP 请求把 Cookie 发出去——中间人能截获并复用。哪怕只有一条 HTTP 请求漏出，session_id 就可能被劫持。
- 生产环境务必设
secure: true，本地调试用localhost时可暂时设false，但上线前必须改掉 - 注意：Nginx 反向代理后，Go 服务可能收不到 HTTPS 头，需手动配置
c.Request.TLS != nil或信任 X-Forwarded-Proto - 不检查协议直接硬编码
false是常见疏忽点
HttpOnly 必须为 true，且不能依赖前端 JS 读取
httpOnly: true 是防 XSS 窃取 Cookie 的第一道防线。一旦设为 false，恶意脚本就能用 document.cookie 拿走 session_id 并发往攻击者服务器。
- 登录态、用户 ID、token 类 Cookie 全部要设
httpOnly: true - 不要为了“前端需要读 session_id”而妥协——需要用的话，改用
localStorage存非敏感标识，或后端透传必要字段到响应体 -
httpOnly对Cookie函数无影响，c.Cookie("name")仍能正常读取，JS 却拿不到
Domain 和 Path 设置不当会扩大泄露面
domain 设太宽（如 "example.com"）会让子域名下的任意页面都能访问该 Cookie；path 设成 "/" 则全站可见——攻击者只要攻陷任意一个子路径的 XSS，就能拿到主站 Cookie。
- 尽量缩小作用域：
domain显式写成"app.example.com"，而非"example.com" -
path按实际路由范围设，比如管理后台 Cookie 设"/admin"，避免前台页面也能携带 - 开发时填
"localhost"是安全的，但上线后必须替换为真实域名，且不能带协议或端口
MaxAge 不要设 0，删除要用 -1
maxAge 传 0 表示“忽略 Max-Age 字段”，浏览器按 Expires 处理（可能变成会话级 Cookie）；而 -1 才是明确告诉浏览器“立刻删掉”。Session 劫持常利用残留 Cookie 复用，没真正删干净就是隐患。
- 登出逻辑中，必须用
c.SetCookie("session_id", "", -1, "/", "app.example.com", true, true) - 不要只清空 value，不设
maxAge: -1—— 浏览器不会删除它 - 同一域名下多个 Cookie，要逐个调用
SetCookie删除，不能只删一个就以为完事
SetCookie 的七个参数里，secure 和 httpOnly 是防御 Session 劫持最刚性的两个开关，其他参数则是控制攻击面大小的边界。漏掉任何一个，都可能让整套认证逻辑形同虚设。 
