必须替换gorilla/sessions默认store为redis实现，否则session仍存内存、重启丢失且分布式下数据隔离；现象为cookie正常但session.values为空，或同id在不同节点读值不一致。
gorilla/sessions 必须替换默认 Store 才能用 Redis
不换 Store，session 还是写在内存里，重启就丢，分布式下各实例数据完全隔离。现象是：Cookie 正常下发，session.Values 却始终为空；或者同一 session.ID 在不同节点读出不同值。
必须显式初始化支持 Redis 的 Store 实现，比如 github.com/boj/redistore（虽归档但稳定）或自己封装 redis/v9 客户端：
-
redistore.NewRediStore要传入已配置好的*redis.Client，不能只改配置文件 - 密钥
keyPairs必须所有服务实例统一，否则解密失败 →session.Values为 nil - 别漏掉
MaxAge设置，它控制 Cookie 过期时间，也需与 Redis TTL 对齐
Redis key 设计要防失效和并发覆盖
直接用 "session:" + userID 当 key 是危险操作：用户登出、换设备、改密码时无法精准清理旧会话，KEYS session:user123* 线上禁用，O(N) 扫描会拖垮 Redis。
正确做法是两级 key：
- 主 session key 用服务端生成的 UUID：
"session:" + sessionID - 额外存一条 hash：
"user_sessions:user123"，value 是[]string{sessionID1, sessionID2} - 登出时先查 hash，再批量
DEL session:xxx，最后HDEL user_sessions:user123 sessionID
写入时务必带 TTL：client.Set(ctx, key, value, time.Duration(maxAge)*time.Second)，漏掉 time.Second 换算会导致过期时间错乱。
v9 客户端必须用 WithContext，别卡死整个请求链
redis/v8 和 v9 行为差异大：v9 的 WithContext 能透传超时与取消信号，v8 则容易因单次 Redis 超时拖垮整个 HTTP handler。
实操要点：
- 所有 Redis 调用必须传带 timeout 的
context.Context，例如ctx, cancel := context.WithTimeout(r.Context(), 500*time.Millisecond) - 启动时用
client.Ping(ctx).Err()验证连接，别等第一个Set才发现地址写错 - 连接池参数不能拍脑袋：PoolSize 建议设为预期 QPS 的 2–3 倍，同时配
IdleTimeout和MinIdleConns防连接泄漏
JSON 序列化字段名大小写不一致导致反序列化静默失败
Go struct 默认导出字段转 JSON 是 PascalCase（如 UserID），但下游系统或前端通常期望 user_id。不加 tag 直接 json.Marshal，存进去的是 {"UserID":"u1"}，读出来却赋值失败，也不报错。
必须显式加 tag：
- 所有要存 Redis 的结构体字段，加小写下划线风格：
UserID string `json:"user_id"` - 存之前先
json.Marshal打印日志，确认输出格式符合预期 - 读取时用
json.Unmarshal([]byte(result.Val()), &s)，别用result.Scan(&s)—— 后者走二进制协议，不解析 JSON
真正麻烦的不是写错，而是没报错：字段非导出、tag 拼错、大小写不匹配，都会让 json.Unmarshal 静默跳过，最终得到一个零值结构体，调试时很难定位。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
