filesystem.store不能用于多实例部署，因其将session数据写入各节点本地文件，节点间完全隔离，导致负载均衡下会话丢失。
Go 的 Echo 框架本身不内置分布式 Session 支持，必须靠中间件组合实现；直接用 filesystem 存储（如官方示例）在多实例部署下必然失效——Session 数据只存本地磁盘，节点间完全隔离。
为什么 filesystem.Store 不能用于生产环境的多实例部署
这是最常被忽略的“伪分布式”陷阱。很多教程直接抄 sessions.NewFilesystemStore 示例，但没说明它只适用于单机调试。
-
filesystem.Store把 session 数据序列化后写入本地文件，每个 Echo 实例读写的是自己机器上的目录，A 实例写入的 session 文件，B 实例根本看不到 - 负载均衡把用户请求轮询分发到不同节点时，
sess, _ := session.Get("xxx", c)在 B 节点永远拿不到 A 节点创建的 session - 即使加了 sticky session（IP Hash），一旦某节点宕机或滚动发布，用户会话直接丢失，违背高可用前提
用 Redis 实现真正的分布式 Session（Echo + gorilla/sessions）
核心是替换 Store 实现，让所有节点共用同一个 Redis 实例或集群。注意：Echo 官方 echo-contrib/session 包只是封装了 gorilla/sessions，真正起作用的是后者提供的 redis.Store。
- 安装依赖：
go get github.com/gorilla/sessions和go get github.com/go-redis/redis/v8 - 初始化 Redis 客户端后，构造
redis.Store：store := redis.NewStore(16, "tcp", "localhost:6379", "", []byte("your-secret-key")) - 注册中间件：
e.Use(session.Middleware(store))—— 此处传入的是gorilla/sessions的Store接口实现，不是echo-contrib自带的FilesystemStore - Session ID 仍由 Cookie 传递，但后端数据全部落 Redis，自动支持过期（
EXPIRE）、原子读写、故障转移
关键配置与易错点
Redis Store 看似简单，但几个参数配错会导致静默失败或安全漏洞。
-
maxAge必须显式设置：在sess.Options中设MaxAge: 3600，否则默认为 0（浏览器关闭即失效），且 Redis 不会自动设 TTL，session 可能永久滞留 -
Path和Domain要匹配前端域名：若前端是app.example.com，Domain应设为.example.com，否则跨子域无法共享 Cookie -
Secure和HttpOnly生产环境必须开启：Secure: true（仅 HTTPS 传输）、HttpOnly: true（防 XSS 窃取 session ID） - Redis 连接池大小要调优：默认 10 连接在高并发下易打满，建议设为
client.SetPoolSize(50)
替代方案：JWT + 无状态会话（适合 API 场景）
如果业务本质是前后端分离的 REST API（如移动端、Vue/React 前端），更推荐跳过 Session，直接用 JWT。
- 登录成功后，服务端签发 JWT（含
user_id、exp、iat），前端存在 localStorage 或内存中 - 后续请求通过
Authorization: Bearer <token></token>传递，服务端用github.com/golang-jwt/jwt/v5验证签名和时效 - 优势：彻底消除服务端状态，水平扩展零成本；缺点：无法主动失效（需加黑名单表或缩短
exp） - 注意：JWT payload 别放敏感信息，密钥（
SigningKey）必须严格保管，别硬编码在代码里
真正难的不是选 Redis 还是 JWT，而是明确你的部署拓扑和客户端类型——如果是传统 SSR 页面（模板渲染），Redis Store 是稳妥选择；如果是纯 API 服务，JWT 更轻量。而 filesystem.Store，只该出现在 go run main.go 本地调试时。
