Go标准库无Session支持，必须自行封装sessionID生成、Cookie设置、数据存储与过期管理；可插拔设计需定义SessionStore接口，统一Get/Set/Delete/GC行为，解耦存储实现。
为什么不能直接用 net/http 的 Session？
Go 标准库压根没有 Session 类型，更不存在内置会话管理。所有“Go 实现 Session”的方案，本质都是自己封装：生成唯一 sessionID、绑定数据、设置 Cookie、配合存储后端读写。不抽象持久化层，很快就会在切换 Redis → SQLite → 文件时重复写序列化/反序列化、连接池、过期逻辑。
如何设计可插拔的持久化接口？
核心是定义一个干净的 SessionStore 接口，只暴露最必要的行为：
type SessionStore interface {
Get(sessionID string) (map[string]interface{}, error)
Set(sessionID string, data map[string]interface{}, expiry time.Duration) error
Delete(sessionID string) error
GC() error // 清理过期会话（非必须，但 Redis/SQL 需要显式调用）
}
关键点：
-
Get和Set必须支持map[string]interface{}，避免强耦合具体结构体；实际使用时再做类型断言或 JSON 解析 -
expiry传入time.Duration，由各实现决定是存 TTL（Redis）、还是存绝对时间戳（SQLite） -
GC()不应在每次Get时自动触发——高并发下可能拖慢请求；建议单独起 goroutine 定期调用
Redis 实现最容易踩的坑
用 github.com/go-redis/redis/v9 时，常见错误包括：
立即学习“go语言免费学习笔记（深入）”；
- 没设置
context.WithTimeout，Redis 挂掉导致整个 HTTP 请求阻塞 - 把 session 数据直接
json.Marshal存成 string，但没处理time.Time或struct中未导出字段——结果读出来是空 map - 用
SET session:abc "{...}" EX 3600手动拼命令，漏掉EX参数导致永不过期
正确做法：
func (r *RedisStore) Set(sessionID string, data map[string]interface{}, expiry time.Duration) error {
ctx, cancel := context.WithTimeout(context.Background(), 500*time.Millisecond)
defer cancel()
b, _ := json.Marshal(data)
return r.client.Set(ctx, "session:"+sessionID, b, expiry).Err()
}
文件系统持久化适合什么场景？
文件存储不是玩具——它适合单机部署、低频访问、调试环境或嵌入式设备。但必须处理：
- 并发写冲突：多个请求同时写同一个 session 文件 → 用
os.OpenFile(..., os.O_CREATE|os.O_WRONLY|os.O_TRUNC)+flock（Linux/macOS）或syscall.LockFile（Windows）加锁 - 目录爆炸：不要把所有 session 文件放在同一级目录，按
sessionID[0:2]分目录，例如/sessions/ab/ab123456.json - 过期清理：无法像 Redis 那样依赖服务端 TTL，必须自己扫描
mtime，且不能在请求中执行——用time.Ticker后台每 5 分钟扫一次
路径构造示例：filepath.Join(r.rootDir, sessionID[0:2], sessionID+".json")
SessionStore 接口的具体实现里。最难的不是写代码，是决定哪些操作该同步阻塞（如 Delete），哪些该异步落盘（如日志记录），以及是否允许部分失败时静默忽略——这取决于你的业务对会话一致性的容忍度。 
