不能直接用 map + sync.RWMutex 管理 session，因 Go map 本身不支持并发读写，易因漏锁、defer 忘解锁或过期清理 goroutine 遍历引发 concurrent map read/write panic。
为什么不能直接用 map + sync.RWMutex 管理 session
很多初学者会写这样的代码：map[string]*Session 加 sync.RWMutex，认为“加锁就线程安全”。但实际运行中常遇到 fatal error: concurrent map read and map write。根本原因在于：Go 的 map 本身不支持并发读写，即使你用 RWMutex 包裹了读写逻辑，一旦漏掉某处（比如遍历未加锁、或 defer 忘了解锁），就会崩溃。更隐蔽的问题是：session 过期清理若用单独 goroutine 遍历 map，极易和业务写入冲突。
用 sync.Map 替代普通 map 的适用边界
sync.Map 确实能避免 map 并发写 panic，但它不是万能解药。它的设计目标是「读多写少」场景，且不支持原子性遍历——你无法安全地获取所有活跃 session 做统计或批量踢出。另外，sync.Map 的 LoadOrStore 返回值是 (interface{}, bool)，类型断言容易出错；过期判断仍需外部维护时间戳字段。
- 适合：单机轻量级服务，session 生命周期短（
- 不适合：需要定时扫描过期、按用户 ID 批量失效、或依赖 session 元数据做路由决策的场景
- 关键提醒：
sync.Map不保证 key 的顺序，也不能用range遍历，必须用Range()方法，且该方法回调中禁止写入 map
goroutine 泄漏：忘记 stop channel 或 context cancel
常见错误是启一个 goroutine 定时清理过期 session，但没提供退出机制：
go func() {
ticker := time.NewTicker(30 * time.Second)
for range ticker.C {
// 清理逻辑
}
}()这段代码在服务重启或配置热更新时会持续运行，goroutine 永不退出。正确做法是传入 context.Context，并在 ctx.Done() 时退出：
立即学习“go语言免费学习笔记（深入）”；
go func(ctx context.Context) {
ticker := time.NewTicker(30 * time.Second)
defer ticker.Stop()
for {
select {
case <-ticker.C:
// 清理逻辑
case <-ctx.Done():
return
}
}
}(ctx)- 务必调用
ticker.Stop()，否则底层 timer 不释放 - 不要用
time.AfterFunc递归启动清理，容易失控 - 清理函数内部避免阻塞操作（如数据库同步写），应投递到 worker channel 异步处理
session ID 生成必须用 crypto/rand
用 math/rand 生成 session ID 是严重安全隐患——它默认种子是时间戳，可被预测。攻击者能伪造合法 session ID 绕过登录校验。
- 必须使用
crypto/rand.Read()生成随机字节，再转为 hex 或 base64 - 长度建议 ≥ 32 字节（256 bit），避免碰撞和暴力枚举
- 示例：
func newSessionID() string { b := make([]byte, 32) _, _ = rand.Read(b) // 注意：这是 crypto/rand return hex.EncodeToString(b) }
session 数据本身是否加密取决于敏感程度；但 ID 绝对不可预测，这是第一道防线。
