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”。
