Go标准库不内置Session支持，因设计哲学强调“小而明确”，需开发者自行实现存储与生命周期管理；Cookie须设HttpOnly、Secure、MaxAge，并用crypto/rand生成ID、登录后轮换ID防固定攻击，Redis是推荐存储方案。
Go 标准库不内置 Session 支持，http.Cookie 只负责传输，Session 必须自己实现存储与生命周期管理。
如何安全地读写 HTTP Cookie
Cookie 是纯客户端存储，不能直接存敏感信息；http.SetCookie 和 r.Cookie 是基础操作入口，但默认无安全防护。
- 始终设置
HttpOnly=true防 XSS 窃取（如http.Cookie{HttpOnly: true}） - 生产环境必须加
Secure=true（仅 HTTPS 传输），否则浏览器拒绝发送 - 避免手动拼接
Set-Cookie头，用http.SetCookie(w, cookie)自动处理转义和格式 -
MaxAge比Expires更可靠：前者是秒数，后者依赖客户端时间，易被篡改
为什么 net/http 没有内置 Session？
Go 设计哲学倾向“小而明确”——Session 涉及存储后端（内存/Redis/DB）、序列化、过期策略、并发安全等权衡，标准库不强制绑定任何一种方案。
- 内存型 Session（如
sync.Map）适合单机调试，但无法横向扩展 - Redis 是最常用选择：
github.com/gomodule/redigo/redis或github.com/go-redis/redis/v9配合 TTL 自动清理 - Session ID 必须用
crypto/rand.Read生成，禁用math/rand（可预测） - 每次请求应校验 Session ID 签名（如 HMAC-SHA256），防止客户端篡改 ID 冒充他人
如何避免 Session 固定攻击（Session Fixation）
攻击者诱使用户登录前就持有合法 Session ID，登录后该 ID 即被授权——关键在于“登录成功后必须换新 ID”。
立即学习“go语言免费学习笔记（深入）”；
- 调用
sessionID = generateNewID()后，立刻在服务端删除旧 Session 数据 - 用新 ID 覆盖原 Cookie：
http.SetCookie(w, &http.Cookie{Name: "sid", Value: sessionID, ...}) - 不要复用登录前的 Cookie 值，哪怕它看起来“随机”
- 若使用第三方库（如
gorilla/sessions），确认其session.Save(r, w)是否自动轮换 ID；默认不轮换，需手动调session.Options.MaxAge = 0触发重置
Redis 存储 Session 的最小可行代码结构
不依赖框架时，Session 数据结构和 Redis 操作要极简可控，避免抽象泄漏。
// Session 结构体只存必要字段，JSON 序列化
type Session struct {
ID string `json:"id"`
UserID int64 `json:"user_id"`
ExpiresAt time.Time `json:"expires_at"`
}
// 写入：带 TTL，避免永不过期
conn.Do("SETEX", "sess:"+sid, 3600, dataBytes)
// 读取：检查是否过期再反序列化
data, _ := redis.Bytes(conn.Do("GET", "sess:"+sid))
var s Session
json.Unmarshal(data, &s)
if s.ExpiresAt.Before(time.Now()) { / 拒绝 / }
Redis key 命名加前缀（如 sess:）便于批量清理；TTL 必须和服务端 Session 过期时间严格一致，不能靠客户端 Cookie 的 MaxAge 单独控制。
