Beego中通过Controller的SetCookie和GetCookie方法设置与读取Cookie：c.SetCookie("key","value",maxAge,path,domain,secure,httpOnly)设置，c.GetCookie("key")读取；注意path、domain、secure等参数需严格匹配，否则前端无法获取。
Beego 中如何设置和读取 Cookie
Beego 的 Controller 提供了原生支持，不需要额外引入包。关键在于用对方法、注意默认参数隐含的行为——比如过期时间不设就是会话级，路径默认是 /，但若你部署在子路径（如 /api），就得显式指定 path 否则前端拿不到。
设置 Cookie：
c.SetCookie("user_token", "abc123", 3600, "/", "example.com", false, true)
读取 Cookie：
token := c.GetCookie("user_token")
-
3600是秒数，设为负数（如-1）表示浏览器关闭即失效；设为0表示立即过期（可用于删除） - 第 4 个参数
"/"是path，必须匹配前端请求路径，否则 JS 无法通过document.cookie访问 - 倒数第二个参数是
secure，HTTPS 环境下必须为true，否则浏览器拒绝发送 - 最后一个
httpOnly设为true后，JS 无法读取，能防 XSS 窃取，但登录态校验逻辑就得全靠后端
为什么 SetCookie 后前端始终读不到
90% 是路径或域名不匹配导致的。Beego 默认写入的 Cookie 路径是 /，但如果前端页面在 https://a.example.com/admin/，而后端接口在 https://api.example.com/，跨域 + 路径不一致就会静默失败。
- 检查响应头中
Set-Cookie字段是否真实存在，用浏览器开发者工具的 Network → Response Headers 确认 - 确保
domain参数与当前页面域名兼容：不能写www.example.com却在example.com下访问；可写.example.com覆盖子域名（但需保证主域名可控） - 如果用了 Nginx 反向代理，确认没被过滤掉
Set-Cookie头（检查proxy_pass_request_headers和proxy_cookie_path配置）
Beego 删除 Cookie 的正确方式
别只依赖前端清除 document.cookie，那是不可靠的。后端必须主动下发一个已过期的同名 Cookie 来覆盖。
c.SetCookie("user_token", "", -1, "/", "example.com", false, true)
- 值设为空字符串没问题，关键是
maxAge设为-1或负数，让浏览器立刻丢弃 - 所有参数（尤其是
path和domain）必须和当初设置时完全一致，否则旧 Cookie 仍残留 - 如果之前设置时用了
secure: true，删除时也得保持，否则 HTTPS 下新 Cookie 不会被识别为同一枚
Cookie 与 Beego Session 冲突怎么办
Beego 默认 Session 实现（memory 或 redis）底层也依赖 Cookie 存储 session id（键名为 beegosessionID）。如果你手动用 SetCookie 写了一个同名的 beegosessionID，会导致 Session 机制错乱——比如用户登出后还能继续操作。
- 避免自定义 Cookie 名称和 Beego 内部使用的重名，推荐命名带业务前缀，如
auth_token、user_prefs - 如果必须共用一套鉴权逻辑，优先走 Beego Session，而不是自己维护 Cookie；Session 更安全，支持服务端销毁
- 调试时可用
c.Input.Cruce().GetSession("xxx")检查 Session 是否生效，比直接读 Cookie 更可靠
Cookie 的 key 名、path、domain、secure 这几项只要有一处不一致，浏览器就视为不同 Cookie。线上环境务必用真实域名+HTTPS 测试，localhost 下的 Cookie 行为和生产差异很大。
