必须异步落库，否则同步写库会阻塞WebSocket读协程导致超时断连；应通过带缓冲channel解耦接收与存储，并建(room_id, created_at)联合索引优化查询。

直接存数据库会卡住 WebSocket 连接，必须异步落库。 否则只要 INSERT 耗时超过几毫秒，conn.ReadMessage() 就可能被阻塞或超时断连——这不是设计问题，是 Go 并发模型下 IO 与业务逻辑混在一起的必然结果。

为什么不能在 ReadLoop 里直接写数据库

WebSocket 的读协程（ReadLoopGroup）本质是单连接单 goroutine 处理入站消息。一旦你在里面调用 db.Exec() 或任何同步 I/O 操作：

• 数据库慢查询、网络抖动、锁等待都会让该 goroutine 卡住，导致后续 ReadMessage() 调用失败或超时
• 客户端心跳（PongHandler）续期失败，服务端主动关闭连接
• 并发用户一多，数据库连接池迅速耗尽，整个服务雪崩

用 channel 做轻量级消息队列（适合中小规模）

不引入 Kafka/RabbitMQ 的前提下，用 Go 原生 chan 实现生产者-消费者解耦，既简单又可控。关键点在于：分离「接收」和「存储」两个阶段。

示例结构：

type MessageRecord struct {
    UserID   string
    Content  string
    RoomID   string
    CreatedAt time.Time
}
// 全局消息通道（带缓冲，防瞬时洪峰）
var msgQueue = make(chan MessageRecord, 1000)
// 启动一个常驻消费者 goroutine
func init() {
go func() {
for msg := range msgQueue {
_, err := db.Exec("INSERT INTO chat_logs (user_id, content, room_id, created_at) VALUES (?, ?, ?, ?)",
msg.UserID, msg.Content, msg.RoomID, msg.CreatedAt)
if err != nil {
log.Printf("failed to persist message: %v", err)
// 此处可加重试、降级或告警，但绝不 panic 或 return
}
}
}()
}

在 WsClient.ReadLoopGroup() 中，收到消息后只做一件事：

• 解析 UserID 和 RoomID（比如从 JSON 消息体或连接 URL query 中提取）
• 构造 MessageRecord 并发送到 msgQueue
• 立刻继续下一轮 ReadMessage()，不等落库结果

如何保证消息不丢（内存队列的底线方案）

纯内存 chan 在进程崩溃时消息全丢。若业务要求「至少一次」投递，需加一层简单兜底：

• 启用 sync.Map 或本地文件暂存未消费消息（仅限开发/测试环境）
• 更稳妥的做法：把 msgQueue 改为 chan *MessageRecord，消费者拿到指针后先 defer 标记“已处理”，再执行 DB 写入；失败时记录日志并触发告警，人工介入补单
• 真正需要持久化保障的场景，请直接上 RabbitMQ 或 Kafka，用 ack 机制替代 channel

RoomID 设计影响查询效率

聊天室数据能否快速回溯，取决于 RoomID 如何生成和索引：

• 避免用随机 uuid 作主键+索引组合，会导致 B+Tree 分裂严重；推荐用 room_20251230_chat101 这类带日期前缀的字符串，利于按天分区归档
• 务必在 (room_id, created_at) 上建联合索引，否则 SELECT * FROM chat_logs WHERE room_id = ? ORDER BY created_at DESC LIMIT 50 会全表扫描
• 如果支持「历史消息分页加载」，不要用 OFFSET，改用 WHERE created_at

最容易被忽略的是：消息体中的敏感内容（如用户昵称、头像 URL）是否要脱敏存储？如果聊天记录要审计或导出，Content 字段建议统一走 json.RawMessage 解析后再入库，而不是原样存字符串——否则未来加字段、改格式时，历史数据就成脏数据了。