Go 的 http.SetCookie 设不上，主要是因响应头未发送或被拦截：必须在写 body 前调用，且需注意代理、SameSite 大小写、Secure 与本地开发冲突、Path/Domain 匹配及 credentials 配置。
Go 的 http.SetCookie 为什么设不上？
浏览器收不到 Cookie，大概率不是逻辑写错了，而是响应头没发出去或被拦截了。Go 默认不自动发送 Set-Cookie，必须显式调用 http.SetCookie，且该函数只写入 ResponseWriter 的 header 缓冲区——如果 handler 已经写了 body（比如调用了 w.Write 或 json.NewEncoder(w).Encode(...)），再调用它就无效。
- 确保在任何
w.Write、fmt.Fprintf(w, ...)、json.Encoder.Encode之前调用http.SetCookie - 检查是否启用了 HTTP/2 或反向代理（如 Nginx）：某些代理默认过滤或重写
Set-Cookie，特别是带Secure或SameSite属性时 -
SameSite值必须是"Strict"、"Lax"或"None"（注意大小写），写成"sameSite"或"none"会导致整个 cookie 被忽略 - 本地开发用
http://localhost:8080时，Secure: true会让浏览器直接丢弃 cookie
用 gorilla/sessions 存 session ID 还是存数据？
它只负责安全地签发、验证和传输 session ID（存在 cookie 里），真正的 session 数据默认存在内存（cookiestore）或外部存储（Redis、PostgreSQL）。别把敏感字段（如密码、token）塞进 cookie 本身——cookiestore 是加密+签名的，但一旦密钥泄露，所有 session 都可伪造；更关键的是，cookie 有 4KB 上限，大数据会截断或报错。
- 生产环境务必换掉默认的
cookiestore，改用redisstore或postgresqlstore，避免重启服务丢失 session - 如果坚持用
cookiestore，密钥长度至少 32 字节，且不能硬编码在代码里，应从环境变量读取：securecookie.GenerateRandomKey(32)只用于开发 - 设置
Options.MaxAge控制过期时间，别依赖Expires字段——后者是客户端时间，不可信；MaxAge是秒数，服务端计算后写入
自己实现 session 管理时，http.Request.Cookies() 返回空怎么办？
不是没 cookie，是没匹配上域名或路径。Go 的 Request.Cookies() 只返回当前请求 URL 路径前缀匹配且域名符合的 cookie（遵循 RFC 6265）。常见漏点：前端发请求时没带 credentials: "include"，导致跨域请求不附带 cookie；或者后端设 cookie 时 Path 写成了 "/api"，但请求 URL 是 /api/v1/login ——这是合法的，但若设成 "/api/"（结尾带斜杠），就可能不匹配。
由 ReMe 驱动的记忆管理系统，支持跨会话记忆持久化、自动应用用户偏好以及智能上下文压缩...
- 前端 fetch 必须加
credentials: "include"，Axios 则要设withCredentials: true - 后端设 cookie 的
Path推荐统一用"/"，除非你明确需要路径隔离 - 检查
Domain字段：设为"example.com"时，sub.example.com不会自动带上；想通配，得写成".example.com"（开头带点） - 用浏览器 DevTools 的 Application → Cookies 面板确认 cookie 是否真实写入，比查
Request.Cookies()更直接
Session 和 JWT 到底该选哪个？
JWT 不是 session 的替代品，而是另一种状态管理思路：session 把状态存在服务端，JWT 把状态存在客户端（签名后的 JSON）。Go 里用 golang-jwt/jwt/v5 签发 token 很方便，但容易忽略两个硬伤：无法主动失效（登出只能靠短有效期 + 黑名单缓存）、payload 大小随字段增多而膨胀（影响 HTTP header 体积）。
立即学习“go语言免费学习笔记（深入）”；
- 用户量小、登出频率低、无强实时权限控制（如“立刻踢掉某设备”）的场景，JWT 省事；否则优先 session
- JWT 的
exp字段是 Unix 时间戳（秒级），别传毫秒时间，否则永远过期 - 别把密码哈希、数据库 ID 直接塞进 JWT payload——这等于把内部标识暴露给客户端；用随机生成的
session_id更安全 - 如果用 JWT，
HttpOnly和Secure对它无效（它存在 localStorage 或内存里），必须靠前端代码防护 XSS 泄露
