WebSocket本身不造成带宽瓶颈，真正拖慢大规模图片分发的是前端编码方式、传输格式选择和服务端处理逻辑；应采用二进制直传、WebP压缩、长度头防粘包、分片重组、静默丢弃旧帧及状态同步等策略优化。
WebSocket本身不造成带宽瓶颈，真正拖慢大规模图片分发的，是前端编码方式、传输格式选择和服务端处理逻辑。关键不是“怎么传更多”，而是“怎么让每张图传得更轻、更准、更省资源”。
用二进制直传代替Base64
Base64会让图片体积膨胀33%，1MB原图变成1.33MB字符串，还额外消耗CPU做编解码。这不是带宽问题，是人为加压。
- 前端获取图片后，跳过
toDataURL()或readAsDataURL()，直接用File或Blob对象调用ws.send(blob) - 截图或Canvas绘制场景，用
canvas.toBlob(callback, 'image/webp', 0.7)输出WebP格式Blob，比JPEG小30%以上 - 确保
ws.binaryType = 'arraybuffer'，让浏览器走原生二进制帧通道
服务端配合跳过无谓解析
如果服务端收到二进制帧后仍转成Base64再存，等于前端优化全白费。
- Node.js（如
ws库）默认接收Buffer，直接写入磁盘或转发CDN，不经过toString('base64') - 对多图连续推送，加4字节长度头+1字节类型标识，避免粘包；不用自定义复杂协议，MessagePack序列化元数据即可
- 单图超500KB时，在前端拆为64KB ArrayBuffer分片，带序号帧头，服务端按序重组——比等浏览器自动分片更可控
客户端侧协同降载
带宽压力不只是“发得多”，更是“收得杂、处理重、丢得懵”。
立即学习“前端免费学习笔记（深入）”；
- 启用二进制帧接收：用
Uint8Array或DataView直接解析结构体，比如前2字节是用户ID、后1字节是动作码，比JSON字符串省40%+带宽 - 静默丢弃旧帧：给每张图消息附带时间戳，客户端判断距当前超5秒即跳过渲染，避免卡顿堆积
- 非关键图走压缩路径：头像、图标类统一转WebP+质量0.5，加载快且内存占用低
架构上规避大图洪峰
与其扛住1000张高清图并发推，不如让90%的图根本不需要实时推。
- 状态同步替代全量广播：怪兽血量、排行榜Top10等用版本号快照+delta更新，新玩家进房间先拉一次全量，之后只收变化
- 高频小图合并下发：100ms窗口内把多张缩略图打包进一个ArrayBuffer，服务端用TypedArray切片解析
- 后台任务改用SSE或短轮询：非实时类图片同步（如用户相册更新通知）不走WebSocket，释放主通道压力
