websocket默认不启用压缩，需通过permessage-deflate扩展由服务端显式开启并配置，客户端自动协商；主流浏览器原生支持，但二进制数据不应压缩，生效须通过抓包或日志实测验证。
WebSocket 默认不启用压缩，但可以通过 permessage-deflate 扩展在客户端和服务端协商启用 zlib 压缩，对文本类消息（如 JSON、XML）实现 60%–80% 的体积缩减。关键不是手动调用压缩函数，而是让协议层自动完成——前提是两端都正确配置并支持该扩展。
确认浏览器与服务端支持 permessage-deflate
现代主流浏览器（Chrome 77+、Firefox 65+、Safari 15.4+、Edge 79+）均原生支持 permessage-deflate，无需额外 polyfill。服务端需明确启用（如 Node.js 的 ws 库、ASP.NET Core 9、Spring WebSocket 等）。若服务端未开启或禁用了该扩展，即使客户端发起协商，握手也会降级为无压缩连接。
- 检查浏览器是否发送了协商头：
Sec-WebSocket-Extensions: permessage-deflate - 服务端响应中应包含相同头字段，并可能附带参数（如
server_max_window_bits） - 可通过浏览器开发者工具的 Network → WS → Headers 查看握手请求/响应
客户端启用压缩（JavaScript 侧）
标准 WebSocket 构造函数本身不暴露压缩配置接口，是否启用完全取决于服务端是否在握手阶段接受 permessage-deflate 协商。但部分封装库（如 ws 的 Node.js 客户端、socket.io-client 5.x+）提供显式选项。纯浏览器环境无需写压缩代码，只需确保服务端已启用即可。
- 普通
new WebSocket(url)会自动参与协商，只要服务端支持，压缩即生效 - 若使用
ws（Node.js 客户端），可传入选项：const ws = new WebSocket('ws://...', { perMessageDeflate: true }); - 避免对二进制数据（如图片、音频 ArrayBuffer）启用压缩——它们通常已压缩，再压反而增加 CPU 开销且收益极低
服务端必须显式开启并合理配置
客户端无法单方面强制压缩，服务端才是决定方。以常用框架为例：
-
Node.js + ws 库：在创建服务器时传入
perMessageDeflate配置对象，例如设置threshold: 1024（仅 ≥1KB 的消息才压缩），避免小消息因压缩开销得不偿失 -
ASP.NET Core 9：在
Program.cs中调用options.DangerDisableCompression = false（默认已启用），并确保未手动关闭 -
Nginx 反向代理：需透传 WebSocket 升级头，禁止重写或过滤
Sec-WebSocket-Extensions字段，否则协商中断
验证压缩是否真正生效
不能只看代码写了“启用”，要实测验证：
- 用开发者工具抓包，对比同一条 JSON 消息在 WebSocket 帧中的
Payload Length（帧负载长度）是否明显小于原始字符串字节长度 - 服务端日志中观察是否打印压缩/解压行为（如
ws库的 debug 日志） - 发送典型消息（如 1KB 以上 JSON），用
ws.on('message', (data) => console.log('size:', data.length))对比启用前后接收长度
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
