WebSocket不支持大数据包直接可靠传输，需依赖分片机制或自定义流协议；自动分片适用于中等数据，超10MB应采用带offset和哈希校验的二进制流协议，并配合缓冲、校验与降级兜底策略。
WebSocket 本身不支持“大数据包”直接可靠传输——它只处理帧（frame），而单帧有隐式大小限制（如多数实现默认上限在几 MB 到几十 MB）。服务器下发超过 65535 字节的数据时，必须依赖分片机制或流式处理策略，否则容易触发内存溢出、连接异常关闭（code=1006）、iOS 进程被杀等问题。
启用并配置自动分片（推荐基础方案）
主流 WebSocket 库（如 ws、websocket-node）默认开启分片，但需确认服务端配置生效：
- 服务端设置
fragmentOutgoingMessages: true（Node.js 的ws库中为skipUTF8Validation和分片开关配合） - 调整
fragmentationThreshold：默认 16KB，若下发的是结构化大 JSON 或中等二进制块（如 2–5MB 图片元数据），可设为65536（64KB）以减少帧数；超 10MB 建议改用自定义流协议 - 客户端无需额外解析——分片由 WebSocket 协议栈自动重组，
onmessage仍收到完整 payload
手动分片 + 带 offset 的二进制流协议（适用于文件/音视频）
当服务器下发的是原始大文件（如 PDF、模型权重、录像片段），不能依赖自动分片，必须设计带元数据的自定义协议：
- 每帧前 4 字节为小端
Uint32表示该片起始字节偏移量（offset），后接实际数据 - 前端接收时维护全局
receiveBuffer = new Uint8Array(totalSize)，用buf.set(chunkData, offset)精确写入 - 服务端每次写入后返回该片哈希（如 xxhash32），前端比对一致才更新本地已接收状态，避免网络丢包导致错位
- 重连后先发查询请求（如
GET /download/status?id=xxx）获取服务端当前最大offset，从该位置续传
接收端缓冲与防卡顿处理
高频或大批量数据推送易阻塞主线程，尤其在解析大 JSON 或渲染大量 DOM 时：
- 使用
binaryType = 'arraybuffer'接收二进制，避免字符串编码开销 - 建立内存缓冲区（如
const buffer = []），累积多条消息再批量处理，控制setTimeout或requestIdleCallback触发解析 - 对超大 JSON，改用流式解析器（如
jsonparse）或 Web Worker 解析，防止 UI 冻结 - 设置缓冲区上限（如 1000 条），超出时丢弃旧数据或告警，防内存泄漏
校验与降级兜底
大数据传输不可信，必须加入完整性保障：
- 服务端下发前计算整包 SHA-256，附在首帧或独立 control 帧中；前端拼接完成后校验
- 监听
onclose事件的event.code：若为1006（abnormal closure），说明可能传输中断，触发重试逻辑 - 对非关键数据（如日志、统计），可降级为分段 HTTP GET 请求，利用浏览器原生断点续传能力
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
