WebSocket传图传文件教程：Base64与Blob对比实战

WebSocket传输图片和文件时，Base64方式虽能实现但存在主线程阻塞、体积膨胀33%、内存冗余拷贝等严重性能缺陷，绝不适合生产环境；真正高效可靠的方案是直接使用Blob实现零拷贝传输，或选用ArrayBuffer进行字节级精细控制（如加帧头、加密、多帧拼接），同时必须严格匹配MIME类型、主动处理Chrome的128KB单帧限制（通过分片）、避免JSON封装二进制数据——让WebSocket回归低延迟、高吞吐的本职定位。

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 是更底层也更灵活的选择：

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

理论要掌握，实操不能落！以上关于《WebSocket传图传文件教程：Base64与Blob对比实战》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！