不建议在 WebSocket 层启用 permessage-deflate 压缩图像数据，因 JPEG/PNG/WebP 等已是高压缩格式，再压缩无效且增 CPU 开销；应优先预压缩、格式优化、动态适配分辨率、HTTP 缓存+WebSocket 推送通知；必须实时传输时，设 binaryType='arraybuffer'、禁用 perMessageDeflate、增量编码、分片组装；仅原始位图（如 RGBA/BMP）才适用 permessage-deflate，需设 threshold≥4096；前端用 createImageBitmap 异步解码并缩放采样渲染。
WebSocket 发送大块二进制图像数据时，**不建议在 WebSocket 层启用 permessage-deflate 压缩**，因为图像本身（如 JPEG、PNG、WebP）已是高度压缩格式，再次用 deflate/gzip 压缩几乎无效，反而增加 CPU 开销和延迟。
优先选择：传输前预压缩 + 格式优化
图像数据的压缩应在生成或编码阶段完成，而非依赖 WebSocket 协议层：
- 用现代图像格式替代传统格式：将 PNG 转为 WebP 或 AVIF，JPEG 转为 JPEG XL，体积可减少 30%–60%，且浏览器原生支持解码
- 服务端动态调优参数：对同一张图，按终端能力（DPR、屏幕尺寸、网络类型）生成不同分辨率/质量版本，避免发送超高清冗余数据
- 启用 HTTP 缓存与 CDN 预热：若图像内容不变，优先走 HTTP GET + Cache-Control，仅用 WebSocket 推送变更通知（如“图片 ID #123 已更新”），而非重复传图
必须走 WebSocket 二进制传输时的处理方式
当实时性要求高（如摄像头流、标注协作），需通过 WebSocket 直接推送图像帧，应采用以下组合策略：
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 前端设置 binaryType = 'arraybuffer'，确保接收的是原始字节，避免 Blob 自动封装带来的额外开销
-
服务端不启用 perMessageDeflate（Node.js ws 库中设
perMessageDeflate: false；ASP.NET Core 中保持EnableCompression = false） - 对连续帧做增量编码：例如使用 Motion JPEG 的差分帧（delta frame）、或基于 Canvas 的局部重绘区域裁剪，只传变化像素块
- 分片发送 + 客户端缓冲组装：单帧过大时拆成多个二进制消息，携带 sequence ID 和 total chunks，前端按序合并 ArrayBuffer 后再 decode
例外情况：可启用 WebSocket 压缩的图像场景
仅当图像数据是未压缩的原始位图（如 RGBA 32-bit raw data、BMP、或 Canvas getImageData() 返回的 Uint8Array）时，permessage-deflate 才有实际收益：
- 典型例子：医疗影像标注系统中，前端用 Canvas 绘制 ROI 区域后导出整帧像素数组，此时数据冗余度高，deflate 压缩率可达 5–8 倍
- 需配合
threshold: 4096（至少 4KB 才压缩），避免小帧引入压缩开销 - 服务端配置示例（ws 库）：
perMessageDeflate: { threshold: 4096, zlibDeflateOptions: { level: 4 } }
前端解码与渲染优化
收到 ArrayBuffer 后，避免主线程阻塞：
- 用
createImageBitmap()异步解码（支持 WebP/JPEG/PNG，比new Image().src = URL.createObjectURL()更高效） - 大图渲染前先缩放采样（如用 OffscreenCanvas resize），再贴到主 canvas
- 图像加载失败时降级处理：记录错误日志 + 触发重传机制（带 checksum 校验）
