必须异步落库，否则同步写库会阻塞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 实现生产者-消费者解耦，既简单又可控。关键点在于：分离「接收」和「存储」两个阶段。
示例结构：
立即学习“go语言免费学习笔记（深入）”；
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 解析后再入库，而不是原样存字符串——否则未来加字段、改格式时，历史数据就成脏数据了。
