WebSocket大文件传输需应用层实现分块机制，核心是字节偏移量（offset）+固定块大小（chunkSize），前端流式切片、后端按offset精准写入，配合幂等校验与最终完整性验证。
WebSocket 本身不提供大文件传输能力，所谓“分块传输”必须由应用层自主设计和实现。它不是协议内置功能，而是前端切片、后端按偏移写入、双方协同校验的完整链路。
分块传输的核心是字节偏移量（offset）+ 固定块大小（chunkSize）
只靠 chunkIndex（如第1片、第2片）无法应对乱序、重传或连接中断——因为服务端不知道这一片该写到文件的哪个位置。用 offset 才能精确定位：比如 offset=2097152 就代表从文件第 2MB 处开始写入，无论前面是否丢包、是否重复，只要写对位置，最终拼接就可靠。
前端切片要流式读取，避免内存爆炸
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 不要用
file.arrayBuffer()一次性加载整个文件 - 改用
file.slice(offset, offset + chunkSize)获取 Blob 片段 - 配合
FileReader.readAsArrayBuffer()异步读取，每次只持有当前块的 ArrayBuffer - 推荐 chunkSize 设为 256KB～1MB（太小增加帧头开销，太大加重内存压力）
每个数据包需携带可解析的元信息
- 建议结构：4 字节小端 offset + 原始二进制数据
- 后端用
Buffer.readInt32LE(0)提取 offset，再用fs.write(fd, buffer, 0, buffer.length, offset)直接写入指定位置 - 不要用
appendFile，否则乱序到达会导致文件错位
服务端必须幂等接收与即时校验
- 每个分片写入后立即
fsync(fd)刷盘，防止断电丢失 - 计算该块哈希（如 xxhash32 或 SHA-256），随响应返回给前端
- 前端比对本地哈希一致，才更新本地 offset 记录（存于 IndexedDB 或 localStorage）
- 若重连后服务端返回的 maxOffset > 本地记录值，说明有分片未达，需从该位置重发
上传完成需显式通知与整体验证
- 前端最后发送一条文本帧：
{"type":"complete","fileId":"xxx"} - 服务端收到后，按 chunkIndex 或 offset 排序读取所有临时分片，流式合并为目标文件
- 合并完成后必须校验整个文件的哈希，不能仅靠“收到 N 片”就认为成功
不复杂但容易忽略
