Echo 必须显式注入 Redis Store（如 redistore.NewRediStore），否则 gorilla/sessions 默认使用内存 CookieStore，导致负载均衡下 session 丢失；需正确配置连接池、密钥、Domain、MaxAge 及 key 命名规范，并统一 TTL 刷新与登出逻辑。
直接用 gorilla/sessions 默认的 CookieStore，哪怕项目里已经接入 Redis，Session 也照样丢——它根本没走 Redis。Echo 本身不提供 Session 实现，必须自己选 store 并显式注入，否则所有 session 数据都留在单个进程内存里，负载均衡一打散，登录态就断。
为什么 Echo + gorilla/sessions 还是拿不到 session 值
常见现象：req.Header.Get("Cookie") 能看到 session_id=xxx，但 session.Values 总是空；或者不同服务实例间 session ID 相同、数据却对不上。
- 根本原因：没替换默认
CookieStore，gorilla/sessions仍在用内存 map 存数据 -
gorilla/sessions只负责解析/签名 Cookie，store 才决定数据去哪——传什么 store，Session 就存哪 - 别被 “连了 Redis” 欺骗：连接配置改了 ≠ store 换了；必须显式调
redistore.NewRediStore(...)或手写实现sessions.Store - 初始化时若
redis.Client或*redis.Pool没提前Ping()验证，第一次Save()就 panic，错误常是redis: nil connection
redistore 初始化必须设对这四个参数
redistore.NewRediStore 看似只传地址和密钥就够了，但高并发下连接池未预热或参数过松，会导致静默失败或超时。
-
MaxIdle和MaxActive必须显式设（如MaxIdle: 32, MaxActive: 128），默认值为 0 表示禁用复用 - 密钥
[]byte("secret-key")必须所有服务实例完全一致，否则解密失败 →Values为空 -
Options.MaxAge必须设正整数（如3600），它同时控制浏览器 Cookie 过期和 Redis key 的 TTL - 别漏掉
Domain: ".example.com"（注意前导点），否则子域名（app.example.com和api.example.com）间无法共享 Cookie
Session ID 和 Redis Key 设计不能图省事
用 "session:" + userID 当 key 是最典型的反模式，登出、密码重置、多设备登录时无法精准失效。
立即学习“go语言免费学习笔记（深入）”；
- Session ID 必须由服务端生成随机串（如
crypto/rand.Read32 字节或 UUID v4），禁止拼接或复用 - Redis key 格式建议统一为
"sess:auth-api:" + sessionID，带应用前缀避免多服务冲突 - 写入必须带 TTL：
client.SetEx(ctx, key, value, ttl)，别用SET+EXPIRE分两步——网络中断时会残留永不过期 key - 登出时不能
KEYS sess:auth-api:user123*（线上禁用），而应维护一个 hash（如"user:sessions:user123"）存当前有效 ID 列表，再批量DEL
中间件里 Save() 调一次就够了，且不能并发写
典型问题：用户刷新页面后有时登录态还在、有时跳回登录页，本质是多个 goroutine 同时修改同一个 *sessions.Session 实例。
-
sessions.Session.Values是map[interface{}]interface{}，非线程安全，两个 handler 同时写会覆盖 - 别在中间件里反复调
session.Save(r, w)；应在业务逻辑结束前统一调一次 - 如果 handler 提前 return（如鉴权失败），TTL 就漏刷——必须在中间件入口读 session 时记录原始 TTL，在出口处用
client.Expire(ctx, key, ttl)刷新 - 结构体存 Redis 前务必加
json:"user_id"这类小写下划线 tag，否则反序列化字段为空也不报错
Session 共享真正难的不是连 Redis，而是让每个环节都“对齐”：Cookie Domain 对齐子域名、MaxAge 对齐 Redis TTL、密钥对齐所有实例、key 命名对齐业务边界、TTL 刷新对齐用户活跃状态。漏掉任意一环，问题都会以“偶发丢失”的形式出现，排查成本远高于初期多写几行配置。
