默认的gorilla/sessions不能用于分布式环境，因其默认cookiestore或filesystemstore将session存于各进程内存，多实例部署时请求分散导致登录态丢失；必须替换为redis等共享存储后端，如go-session/redis，并正确配置连接池、超时、前缀及序列化方式。
为什么默认的 gorilla/sessions 不能直接用于分布式环境
因为 gorilla/sessions 默认使用内存存储（CookieStore 或 FilesystemStore），每个进程维护独立 session 状态。部署多个服务实例时，用户请求落到不同机器上，就无法读取之前写入的 session 数据——表现为登录态丢失、购物车清空等典型问题。
必须替换为支持共享后端的 store，而 Redis 是最常用且低延迟的选择。
用 gorilla/redisstore 替换默认 store 的关键步骤
gorilla/redisstore 是官方推荐的 Redis 后端扩展，但注意它已归档，实际应使用社区维护的 github.com/gorilla/sessions/v2 + github.com/boj/redistore 或更现代的 github.com/go-session/redis。当前最稳定的选择是 github.com/go-session/redis，它原生支持 context 和连接池。
- 安装依赖：
go get github.com/go-session/redis - 初始化 store 时必须传入 *redis.Client（不是 redis.Conn 或 URL 字符串）；用
redis.NewClient()构建，别用已废弃的redis.Dial() - 设置
Options.HttpOnly = true和Options.Secure = true（生产环境需 HTTPS） - 务必调用
store.Options(sessions.Options{...})显式覆盖默认选项，否则 MaxAge 可能为 0，导致 cookie 立即过期
Redis 连接配置不当引发的超时与连接泄漏
常见错误是直接用 redis.NewClient(&redis.Options{Addr: "localhost:6379"}) 而不设超时和连接池参数，结果在高并发下出现 read tcp ...: i/o timeout 或 too many open files。
- 必须设置
DialTimeout、ReadTimeout、WriteTimeout（建议均为 5 秒） -
PoolSize建议设为 CPU 核数 × 4，最小不低于 10；避免用默认的 10 导致争抢 - Session key 默认前缀是
sessions:，可通过store.SetPrefix("myapp:sess:")隔离不同服务 - Redis 中 session value 是 gob 编码的字节流，不兼容其他语言客户端；如需跨语言，得自己实现 JSON 序列化并替换
store.Codec
中间件中如何安全读写 session 并处理失效
不要在 handler 开头就调用 store.Get(r, "mysession") 后直接用 session.Values["user_id"]，未检查 error 会导致 panic；也不要在 defer 中调用 session.Save()，可能因 response 已写出而失败。
- 每次获取 session 后必须检查 error：
if err != nil { http.Error(w, "session error", http.StatusInternalServerError); return } - 修改 session 后立即调用
session.Save(r, w)，并在其后检查 error；若失败，说明响应头已发送或网络异常，此时无法再写 cookie - Redis 中 session 过期由
MaxAge控制，但 cookie 自身也有过期时间，两者需一致；设置session.Options.MaxAge = 3600时，Redis TTL 也应设为 3600，否则会出现 cookie 过期但 Redis key 还存在的情况
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
