base64编码导致图片体积膨胀33%，易超websocket单帧默认限制（64kb–1mb），触发代理或浏览器断连；且字符串传输绕过二进制通道，增加编解码负担与内存压力。
WebSocket 传图片用 Base64 是能跑通，但不推荐作为生产方案——它会放大传输体积、增加编解码负担、更容易触发帧长度限制断连。
Base64 编码后发图片，为什么容易断连？
WebSocket 单帧默认有大小限制（如 ws 库默认 100MB，但很多代理/浏览器实际限制在 64KB–1MB）。一张 500KB 的 JPEG 图片 Base64 后变成约 670KB 字符串，再套一层 JSON 就可能超限。
-
Base64编码使原始二进制体积膨胀约 33% - 前端
toDataURL()生成的是字符串，send()时不再走二进制通道，无法被服务端直接识别为Buffer - 服务端收到后必须手动
Buffer.from(data.split(',')[1], 'base64')，多一次 CPU 解码 - Chrome/Firefox 对超长字符串消息的
onmessage处理延迟明显，卡顿感知强
如果非要用 Base64，至少避开这几个坑
仅限调试、小图（
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 发送前检查是否含
data:image/xxx;base64,前缀，避免重复拼接 - 服务端解析时用正则提取 base64 内容，别直接
atob()整个字符串（可能含空格或换行） - 不要把
toDataURL()结果再JSON.stringify()包一层——这是双重字符串化，纯属自找麻烦 - 移动端注意 iOS Safari 对超长字符串的
WebSocket.send()有时静默失败，需加try/catch+ws.bufferedAmount监控
替代方案：ArrayBuffer / Blob 直传更靠谱
这才是 WebSocket 传图的现代做法。服务端发 Buffer，客户端收 ArrayBuffer，零中间编码。
- 服务端（Node.js +
ws）：确保ws.send(imgBuffer, { binary: true })，且imgBuffer是原始Buffer，不是toString('base64') - 客户端设置
socket.binaryType = 'arraybuffer'（必须在open后立刻设） - 接收时判断
event.data instanceof ArrayBuffer，别用typeof event.data === 'string'错判 - 构造 Blob 时 MIME 类型要匹配实际格式：
new Blob([event.data], { type: 'image/jpeg' })，错写成image/png会导致 Canvas 绘制失败
Canvas 绘制前必须做类型校验
很多人卡在这步：Blob URL 创建了，img.src 赋值了，但 Canvas 什么都不画。根本原因常是数据损坏或类型不匹配。
- 用
img.onerror = () => console.error('Image load failed:', img.src)捕获加载失败 - 不要跳过
img.onload直接 draw —— Canvas 画的是空图像 - 若需像素级操作（比如灰度处理），用
URL.createObjectURL(new Blob([event.data]))后再fetch()→arrayBuffer()→Uint8Array，比直接createObjectURL多一层可控性 - 频繁绘制时记得
URL.revokeObjectURL()，否则内存泄漏肉眼可见
真正难的不是“怎么传”，而是“怎么让每一帧都稳、准、快”——协议头设计、分片重传、MIME 自动探测、Canvas 渲染节流，这些细节才决定实时图像流能不能落地。
