Go HTTP 中设置Cookie必须用http.SetCookie，读取用req.Cookie；Cookie仅传Session ID，服务端需自行存储Session数据并管理过期；SameSite需按场景选Strict/Lax/None，None必须配Secure。
Go HTTP 中如何设置和读取 Cookie
Go 标准库 net/http 提供了原生支持，不需要第三方包就能完成基础 Cookie 操作。关键在于理解 http.SetCookie 和 req.Cookie 的行为差异——前者写入响应头，后者从请求头解析，且默认不自动处理过期、Domain、Path 等属性。
常见错误是直接拼接字符串写入 Header.Set("Set-Cookie", "...")，这会绕过标准编码逻辑，导致特殊字符（如空格、分号）被截断或解析失败。
- 设置 Cookie 必须用
http.SetCookie(resp, &http.Cookie{...})，不能手动构造字符串 - 读取时用
req.Cookie("name")，它会自动解码 URL 编码值；若需多个同名 Cookie，改用req.Cookies() -
http.Cookie的MaxAge优先级高于Expires；设为负数表示“立即过期”，设为 0 表示“浏览器关闭后失效” - 敏感 Cookie 务必设置
HttpOnly: true和Secure: true（仅 HTTPS 传输），否则前端 JS 可读取或明文发送
为什么 net/http 的 Cookie 不等于 Session
Cookie 是客户端存储机制，Session 是服务端状态管理概念。Go 标准库没有内置 Session 支持，http.Cookie 只负责传输一个 ID（比如 session_id=abc123），真正的 session 数据必须由开发者自行存到内存、Redis 或数据库中。
容易踩的坑是把用户数据（如用户名、权限）直接塞进 Cookie 值里并标记 HttpOnly: false，以为“加密了就安全”。实际上只要没签名或加密，客户端可任意篡改；即使加了签名，也应避免在 Cookie 中存放敏感字段。
立即学习“go语言免费学习笔记（深入）”；
将一个或多个 UI 原型图、线框图、产品截图或设计稿转换为标准化、可直接交付的 PRD 风格文档，供产品、设计、前端和测试共同使用。适用于 Codex 需要分析 PC 网页、桌面端、移动端、响应式页面、独立弹窗、表单、表格、看板、数据大屏或多页面流程截图，还原页面结构与交互，强制套用固定文档模板，抽取跨页面共享规则，或把一组原型沉淀为单页规范文档加整体业务流程文档的场景。不适用于纯视觉审美点评、代码实现、接口设计、埋点方案、竞品分析或无 UI 输入的业务需求创作。
- Session ID 应使用 cryptographically secure 随机数生成，推荐
crypto/rand.Read+ hex 编码 - 务必对 Cookie 值做签名（如 HMAC-SHA256），验证通过才信任其内容；更稳妥的做法是只存 ID，查服务端存储
- 不要依赖
MaxAge清理服务端 session，它只控制客户端行为；服务端 session 过期必须独立维护（如 Redis TTL）
基于 Redis 实现带过期的 Session 存储
用 Redis 存 Session 是最常见做法，关键是把 Cookie ID 和服务端数据生命周期对齐。Go 生态中 github.com/gomodule/redigo/redis 或 github.com/go-redis/redis/v9 都可选，但要注意连接池复用和上下文超时控制。
典型流程：收到请求 → 解析 Cookie 得到 session_id → Redis GET → 若存在且未过期，反序列化为 struct；若不存在或过期，新建 session 并 Set 带 TTL 的 key。
- Redis Key 建议加前缀，如
sess:abc123，避免和其他业务 key 冲突 - TTL 应略大于 Cookie 的
MaxAge（比如 Cookie 设 30 分钟，Redis 设 31 分钟），防止因时间不同步导致“客户端还有效、服务端已删”的不一致 - 每次成功读取 session 后，建议调用
EXPIRE延长 TTL（即“滑动过期”），否则固定过期时间会导致用户长时间操作后突然登出 - 删除 session 时，除了删 Redis key，还要用
http.SetCookie发送 MaxAge=0 的覆盖 Cookie，确保客户端清除
SameSite 属性与 CSRF 防御的实际影响
Go 1.11+ 的 http.Cookie 支持 SameSite 字段，但它不是布尔值而是枚举：SameSiteStrictMode、SameSiteLaxMode、SameSiteNoneMode。错误设置会导致 Cookie 在跨站请求中不被发送，进而破坏登录态或表单提交。
典型问题：后台 API 被前端 Vue/React 单页应用跨域调用，却把 Cookie 设成 SameSiteStrictMode，结果每次请求都拿不到 session_id。
- 普通 Web 页面推荐
SameSiteLaxMode：允许 GET 类跨站请求携带 Cookie（如点击链接跳转），阻止 POST 等危险方法 - 纯前后端分离项目（前端域名 ≠ 后端 API 域名），必须设
SameSiteNoneMode，且强制搭配Secure: true（否则浏览器拒绝） - Chrome 80+ 对
SameSite=None无Secure的 Cookie 会静默丢弃，错误日志里不会报错，只能抓包看响应头是否生效
Cookie 和 Session 的边界容易模糊，真正麻烦的从来不是怎么写那几行 SetCookie，而是过期策略、存储一致性、跨域场景下的 SameSite 组合、以及服务端 session 清理时机——这些地方一漏，轻则用户体验断层，重则出现越权或会话固定漏洞。
