我有一个接收压缩数据的 node.js ws websocket。
文档中关于膨胀机制的内容非常浅薄，但通过阅读源文件，它显然是内置的，应该根据接收到的数据类型自动激活。
但是，当附加ws.on('message',function(data){})事件时，它会返回一个< Buffer >
因为我知道这些流之前已经用 Pako 进行了膨胀，所以我尝试安装它，它实际上使用以下代码工作：
pako.inflate(data, { to: 'string' })
据我了解，这两个模块都使用 zlib 解压缩，但 ws 模块不知何故错过了它。
有人可以给出合理的解释或至少假设为什么吗？
支持的是一个名为 " permessage -deflate"ws的特定 WebSocket 扩展。
此扩展记录在RFC 7692中，并且由于它是协议的扩展，因此底层 WS 协议实现（服务器和客户端）需要支持（其中涉及握手过程，客户端和服务器尝试确定是否对方支持它，发送方设置一个特定的帧标志来通知接收方该帧已被压缩）。
一旦它被激活，它就相对透明，并且帧（解）压缩由协议驱动程序自动处理。
在您的情况下，听起来好像在 WebSocket 之上添加了一个显式压缩/解压缩阶段，其中发送方显式压缩数据（而不是 WS 帧本身），而接收方需要显式解压缩它，这基本上是您已经拥有的发现：收到的消息是一个（压缩的）缓冲区，您需要显式解压缩它。
所以这并没有ws遗漏任何东西，只是（解）压缩发生在原始 WS 帧之上的层中（如果“permessage-deflate”扩展处于活动状态，可能会导致数据被压缩和解压两次：一次是用户码，一次是协议码）。