websocket本身不支持可靠的大文件传输，必须前端分片+后端按偏移写入：前端用blob.slice()切片并附带{id, offset, size, total}元数据，后端fs.write()直接落盘，重连后以服务端最大offset为准续传，并全程哈希校验。
WebSocket 本身支持分片，但浏览器和服务端的实现差异大，不能依赖自动分片来传大文件。10MB 以上直接 send ArrayBuffer，极大概率失败——不是协议不行，而是内存、缓冲区、超时策略不一致导致的。
别信浏览器自动分片
Chrome/Firefox/Edge 在发送超大 ArrayBuffer（比如 20MB+）时确实会底层拆帧，但这个行为：
- 没有公开阈值，不同版本可能从 4MB 切到 64MB 不等
- 不暴露 FIN 和 opcode 给 JS 层，你无法感知是否被切、切了几段
- 服务端若用
ws.on('message', ...)之外的方式收数据（比如监听'data'），就绕过了 WebSocket 帧解析，必然收错或丢帧 - DevTools 的 Frames 面板能看实际结构，但仅限调试，不能用于逻辑判断
Node.js 侧 ws 库配置要点
使用 ws 库时，光开 fragmentOutgoingMessages: true 不够，必须同步调整关键参数：
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
-
fragmentationThreshold默认只有 16KB，对文件传输太小；建议设为65536（64KB）或262144（256KB） - 服务端接收必须用
ws.on('message', (data, isBinary) => {})，不能改用ws.on('data', ) - 注意：这个配置只影响服务端 → 客户端方向；客户端发 ArrayBuffer 仍走浏览器自动分片，不受此控制
真正可控的方案：前端分片 + 后端按偏移写入
这是跨平台最稳的做法，绕过协议层不确定性：
- 前端用
file.slice(offset, offset + chunkSize)得到 Blob，转 ArrayBuffer 后发送 - 每片附带元数据，例如
{id: 'abc123', offset: 0, size: 65536, total: 12}（JSON 字符串或二进制头） - 后端用
fs.write(fd, buffer, 0, length, offset)直接落盘，避免追加写造成乱序覆盖 - 每片到达就写磁盘，不要等全收完再拼 Buffer，防止内存堆积
- 重连后先查服务端已收最大 offset，比对本地记录，以服务端为准续传
校验与容错不能省
网络不可靠，仅靠顺序收齐分片远远不够：
- 发送前算整个文件的 xxhash32 或 SHA-256，随首片一起发过去
- 每片到达后，服务端也计算该片哈希，比对一致才写盘；不一致则拒绝并通知重发
- 合并完成后必须校验整体哈希，不能只数分片个数——缺一片、重复一片、错位一片都难发现
- 设置超时窗口（如 5 秒内未收齐），主动中止或清理临时状态
