Base64不推荐用于WebSocket传图片，因编解码阻塞主线程、体积膨胀33%、内存拷贝冗余；应优先用Blob零拷贝直传，或ArrayBuffer做字节级控制，注意分片与MIME类型严格匹配。
WebSocket 发送图片和文件，Base64 方式能跑通但不推荐用于生产；真正该用的是 Blob 或 ArrayBuffer 直传——体积小、内存少、帧率高，尤其对实时图像流。
为什么 Base64 在 WebSocket 里很慢
不是 WebSocket 不行，是 Base64 自身设计导致三重开销：
-
atob()/btoa()编解码过程强制主线程阻塞，大图（>500KB）易卡顿 - 原始二进制数据膨胀约 33%，比如一张 800KB 的 JPEG 变成约 1.07MB 的字符串，带宽和延迟直线上升
- 浏览器需额外分配内存构造字符串对象，再由 WebSocket 序列化为 UTF-8 字节流，中间多一次拷贝
- 服务端收到后还得
Base64.decode()回去，白费 CPU，还无法利用 WebSocket 的binaryType = 'arraybuffer'原生通道
用 Blob 发送图片的正确姿势
Blob 是浏览器最轻量的二进制载体，零拷贝发送，兼容 IE10+，适合绝大多数前端直传场景：
- 上传时：直接
ws.send(file)或ws.send(blob)，无需任何转换 - Canvas 截图：用
canvas.toBlob(callback, 'image/jpeg', 0.9)，避开toDataURL() - 接收端若需复用：
new Blob([event.data], { type: 'image/jpeg' })构造新 Blob（注意 MIME 类型必须匹配） - 高频更新（如视频帧）记得调用
URL.revokeObjectURL(url)，否则内存持续增长
ArrayBuffer 更适合需要字节级控制的场景
当你需要加协议头、做加密、拼接多帧或对接 C++/Rust 后端时，ArrayBuffer 是更底层也更灵活的选择：
PigX UI 前端开发
下载
PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。
立即学习“前端免费学习笔记（深入）”；
- 发送前用
new Uint8Array(buffer)写入帧头（例如 4 字节长度 + 1 字节类型），解决粘包 - 服务端（如 Node.js
ws库）收到后直接当Buffer处理，跳过所有编码环节 - 前端接收时确保
ws.binaryType = 'arraybuffer'，否则event.data可能是Blob - 不要手动把
ArrayBuffer转成String再 send——那又绕回 Base64 的坑里了
Chrome 的 128KB 单帧限制不是硬伤，但得主动分片
Chrome 对单次 ws.send() 的 ArrayBuffer/Blob 有隐式大小限制（约 128KB），超限会抛 InvalidStateError，但这是可绕过的：
- 服务端无需改——Node.js
ws默认支持最大 100MB 的帧（取决于系统内存） - 前端分片逻辑要自己加：按 64KB 切
Uint8Array，每片加序号和总片数字段，接收端拼接还原 - 别用
JSON.stringify()包二进制数据——它不支持ArrayBuffer，会变成空对象{} - 真要传大文件（>5MB），优先考虑
fetch+multipart/form-data，WebSocket 专注低延迟小载荷
真正容易被忽略的点是 MIME 类型一致性：服务端发 image/png，客户端 new Blob([data], { type: 'image/png' }) 就必须严格匹配，错一个字符（比如写成 image/jpg）会导致 createObjectURL 生成的 URL 无法加载图片。
