websocket不保存历史消息，需服务端持久化存储+客户端按需拉取+websocket实时补推三者配合：服务端存消息到数据库并生成有序id，客户端连接后主动请求历史记录，新消息先落库再广播，并支持离线补偿。
WebSocket 本身不保存历史消息，它只负责实时传输。要实现聊天室历史消息同步，必须结合服务端持久化存储 + 客户端按需拉取 + WebSocket 实时补推，三者配合才能既保证首次进入时看到旧消息，又确保后续消息不丢失。
服务端必须存消息，不能只靠内存广播
很多新手用 WebSocket 写聊天室时，只在内存里维护一个连接列表，收到消息就立刻广播给所有在线客户端——这种方式完全无法支持历史消息。用户一刷新页面，之前聊的内容就没了。
- 每次收到新消息，服务端要先存入数据库（如 MySQL、PostgreSQL）或高性能 KV 存储（如 Redis），至少保留关键字段：消息 ID、发送人、接收房间/用户、内容、时间戳、消息类型
- 建议为每条消息生成唯一且有序的 ID（如 Snowflake ID 或时间戳+序列号），避免并发插入导致顺序错乱
- 对高频聊天室，可按天/按房间分表，或用 MongoDB 的时间戳索引做范围查询，提升历史拉取性能
客户端首次连接时主动请求历史记录
WebSocket 连接建立后（onopen 触发），不能等服务端“推”历史消息，而是要立即发一条查询请求。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 例如：连接成功后，客户端发送
{"type":"fetch_history","room_id":"chat_123","limit":50,"before_ts":1723578600000} - 服务端收到后，从数据库查出该房间最近 50 条、时间早于指定时间戳的消息，按时间倒序返回 JSON 数组
- 前端收到后，追加到聊天记录 DOM 中，并滚动到底部；注意做防重复渲染（比如用消息 ID 去重）
新消息到达时，服务端既要广播也要落库
历史消息和实时消息不是二选一，而是并行处理流程：
- 用户 A 发送消息 → 服务端先写库（确保持久化）→ 再通过 WebSocket 向当前在线的房间内所有人广播
- 广播消息体中应包含完整字段，包括服务端写库后返回的自增 ID 或唯一 msg_id，方便客户端做本地去重和排序
- 如果某用户 B 正好离线，他的连接断开，服务端需标记其“离线”，并在他重连后，根据最后已知的 msg_id 或时间戳，推送未接收的消息（即离线消息补偿）
补充细节：避免时间不准导致漏消息
纯靠客户端本地时间做分页或断点续传不可靠。更稳妥的做法是：
- 服务端统一用 UTC 时间戳（如
Date.now()），所有消息入库时都带这个字段 - 客户端首次拉历史时，传的是“最多拉多少条”+“拉到哪条为止”，而不是“从几点开始”
- 每次拉取后，记录下返回数组中最早那条消息的
msg_id或created_at，下次请求带上作为before_id或before_ts参数 - 前端展示时，按服务端返回的
created_at排序，不依赖接收顺序
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
