websocket 的 permessage-deflate 压缩由浏览器自动处理，需服务端启用并正确配置（如 ws 库设 permessagedeflate: true 及 threshold: 1024），nginx 需透传 sec-websocket-extensions 头；文本类消息自动压缩解压，开发者无感，但二进制、极短文本及高熵数据不宜压缩。
JavaScript 中 WebSocket 本身不直接提供压缩 API，但浏览器原生支持 permessage-deflate 扩展——只要服务端启用，客户端会自动协商并透明完成压缩/解压，无需改业务代码。
确认服务端已开启 permessage-deflate
这是前提。比如 Node.js 的 ws 库需显式配置：
- 必须设置
perMessageDeflate: true或详细对象 - 建议设
threshold: 1024（小于 1KB 不压缩，避免小消息反增开销） -
serverNoContextTakeover: false可提升连续消息的压缩率
若用 Nginx 代理，还需确保它不剥离 Sec-WebSocket-Extensions 头，否则协商失败。
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
浏览器自动处理，无需 JS 主动压缩
启用成功后，所有 socket.send("文本") 都会被自动压缩传输：
- 发送时：浏览器检测消息长度 > threshold → 调用 zlib deflate 压缩 → 封装成 WebSocket 帧
- 接收时：自动解压 → 触发
message事件，event.data仍是原始字符串 - 开发者完全无感，JSON、日志、通知等文本类消息天然受益
不适合压缩的场景要避开
不是所有数据都适合走 permessage-deflate：
- 二进制数据（如图片 ArrayBuffer、已压缩的 Protobuf）——再压缩几乎无效，还白耗 CPU
- 极短文本（如
"pong"、单个数字）——压缩后可能比原文还大 - 加密后的随机字节流（熵高，无冗余，zlib 无法压缩）
验证是否生效的简单方法
不用抓包也能快速判断：
- 打开 Chrome DevTools → Network → 找到 WebSocket 连接 → 点击 Headers → 查看
Request Header是否含Sec-WebSocket-Extensions: permessage-deflate - 对比相同消息在开启/关闭压缩时的帧大小（Frames 标签页），典型 JSON 消息可减少 60%+ 体积
- 服务端日志或监控中观察 CPU 使用变化（压缩会略升 CPU，但带宽下降明显）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
