WebSocket本身不支持断点续传，需前端状态管理与后端分片校验协同实现；关键在用offset+chunkSize标识分片、服务端幂等写入、前后端哈希校验达成原子共识。
WebSocket 本身不支持断点续传，必须靠前端状态管理 + 后端分片校验协同实现。 它没有内置的“已传多少字节”元数据或重连后自动恢复位置的能力。所谓“WebSocket 断点续传”，本质是用 WebSocket 作为传输通道，把分片上传逻辑搬进来——关键不在协议，而在你如何设计分片标识、偏移记录和重连后的状态同步。
为什么不能直接用 send() 传整个文件
WebSocket 单帧（frame）在多数客户端/服务端有默认大小限制：Tomcat 默认 8KB，Undertow 默认 64KB，iOS 的 SRWebSocket 会把整块 NSData 加载进内存。传一个 200MB 文件：
- 内存峰值飙升，可能触发 iOS
JetsamEvent杀进程 - 单帧超限导致连接被服务器静默关闭，无明确错误码
- 网络中断后，无法知道“卡在第几片”，只能全量重试
- 无法与上传进度条、暂停按钮联动——因为没分片索引
offset + chunkSize 是最稳的分片标识方案
比起只传 chunkIndex（如 0, 1, 2…），用文件偏移量（offset）作为每片的唯一定位依据，能让后端完全无状态：收到 offset=5242880 的包，就往文件的 5MB 处写入，不管前面有没有丢、有没有乱序。
前端实现要点：
立即学习“前端免费学习笔记（深入）”；
- 用
NSFileHandle（iOS）或FileReader.readAsArrayBuffer()（Web）配合slice()精确读取指定offset和长度 - 每个 WebSocket 数据包结构建议为：
4 字节 offset（小端） + 原始二进制数据，后端用Buffer.readInt32LE(0)解析 - 不要依赖 WebSocket 连接时长来维护
offset，而应存在IndexedDB或localStorage中（Web）；iOS 用NSUserDefaults或文件标记 - 重连成功后，先发一个查询请求（HTTP 或 WebSocket ping 帧带
fileId），从服务端拉取当前最大offset，再决定从哪继续
重连后怎么避免重复写、错位写
这是最容易出数据损坏的地方。仅靠前端记录 offset 不可靠——比如网络抖动导致包发出但服务端未收到，前端却以为成功了。
安全做法是服务端做幂等写入 + 前端做二次确认：
- 服务端接收每个分片后，立即
fseek(fd, offset, SEEK_SET); fwrite(data, 1, len, fd); fsync(fd);，并返回该offset+len的校验和（如xxhash32） - 前端收到响应后，用相同算法算本地分片哈希，比对一致才更新本地
offset记录 - 如果重连后服务端返回的已接收最大
offset大于前端记录值，说明有包丢失，需从该位置重发；若小于，则说明前端状态错乱，应以服务端为准 - 合并阶段必须校验总文件大小和整体哈希，不能只数分片个数
真正难的不是切片或发包，而是让前后端对“哪一段已落盘”达成原子级共识。很多线上故障都源于前端乐观更新 offset 后没等响应就发下一片，结果网络延迟叠加导致错位写入——这种 bug 在测试环境极难复现，上线后才爆发。
