分片传输需前端主动切块、错峰发送并流式接收拼接，优先转为 uint8array 分片，用 requestidlecallback 节流，接收端校验哈希确保完整。
直接用 ws.send() 发送超大文本（比如几十 MB 的 JSON 或日志）会导致主线程卡顿，因为 JavaScript 需同步序列化、编码、拷贝整个字符串到底层缓冲区。分片传输的核心不是“让 WebSocket 分片”，而是前端主动切块、错峰发送，配合流式接收与拼接逻辑，从而释放主线程。
分片前先转为二进制更可控
文本数据不要以原始字符串形式发送，尤其超过几 MB 时。应先用 TextEncoder 编码为 Uint8Array，再按固定大小（如 64KB）切片：
- 避免字符串重复解析和 UTF-8 编码开销
- 切片操作基于
ArrayBuffer.slice()，不复制内存，仅创建视图 - 后续可统一走二进制帧路径，服务端处理更一致
用 requestIdleCallback 或 setTimeout 控制发送节奏
不能一口气把所有分片 send() 出去，否则仍会挤占主线程。推荐方式：
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 用
requestIdleCallback()在浏览器空闲时段发下一块（兼容性需 fallback 到setTimeout(..., 0)） - 每发送 3–5 块后暂停一次，给渲染和事件响应留出时间
- 监听
ws.bufferedAmount，当它超过阈值（如 1MB）时主动暂停，等drain类似事件（需自行模拟：监听message或定时轮询）再恢复
接收端需应用层拼接与校验
浏览器虽自动重组分片帧，但无法保证网络不丢帧。安全做法是：
- 首块带上总长度和校验码（如 xxHash32），例如：
{type:"chunk_start", total:123456789, hash:"a1b2c3...", index:0} - 每块附带序号
index和当前偏移offset，接收端用Uint8Array.set(chunkData, offset)写入预分配的 buffer - 收完全部后比对最终哈希，不匹配则触发重传请求（通过另一条控制通道）
替代思路：改用 ReadableStream + fetch 流式上传
若目标只是传超大文本且无需实时双向交互，不建议强用 WebSocket。更轻量稳定的做法是：
- 构造
Blob或ReadableStream（来自new TextEncoder().encode(streamingSource)） - 用
fetch(..., { method: 'POST', body: stream })上传，现代浏览器支持流式发送，内存占用恒定 - 进度通过
upload.onprogress监听，服务端返回状态用独立 WebSocket 连接推送
WebSocket 不是文件或大数据管道，它是消息通道。分片传输的本质是“应用层流控”，不是协议功能。做对切块、节流、校验三件事，就能既防卡顿又保可靠。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
