WebSocket发送图片和文件教程前端Base64传输与Blob传输对比【实战】-js教程-PHP中文网

base64不推荐用于websocket传图片，因编解码阻塞主线程、体积膨胀33%、内存拷贝冗余；应优先用blob零拷贝直传，或arraybuffer做字节级控制，注意分片与mime类型严格匹配。

websocket发送图片和文件教程前端base64传输与blob传输对比【实战】

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+，适合绝大多数前端直传场景：

PigX UI 前端开发

PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。

下载

上传时：直接 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 是更底层也更灵活的选择：

发送前用 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 无法加载图片。