Node zlib：内部数据库小字符串压缩选Gzip/Deflate/DeflateRaw？

嘿，针对你说的这个「只在服务器存1-10KB小字符串、不用来传输」的场景，我来分享下我的看法～

1. 带头部的Gzip完全没必要！ #

Gzip的头部（包含标识、时间戳、压缩方法等字段）大概有10-15字节，对于1-10KB的小字符串来说，这个额外开销的占比真的挺显眼——比如1KB的字符串，头部就占了1%以上的空间，完全违背了你「节省存储」的核心需求。而且你不需要让其他设备识别这个压缩格式（毕竟只有服务器自己存自己读），所以带头部的Gzip在这里属于纯浪费。

2. Deflate和DeflateRaw都可以用，甚至更合适！ #

先理清这俩的区别：

• 标准Deflate（RFC 1951）：本身是不带头部的纯压缩数据流，但很多常用库（比如zlib）的Deflate实现会加个极简封装——2字节的头部+4字节的校验和，总共6字节开销，对于10KB级别的字符串来说几乎可以忽略不计，实现起来也简单。
• DeflateRaw：就是完全纯的Deflate压缩流，连那6字节的zlib封装都去掉了，是极致节省空间的选择。如果你用zlib的话，只需要调用deflateInit2时指定MAX_WBITS=-15就能生成，解压时对应设置同样的参数就行。

3. 关于反对Deflate的常见理由——对你的场景不成立！ #

我知道大家吐槽Deflate大多是因为传输场景的兼容性问题：早年有些浏览器或服务器对Deflate的实现不统一（有的用zlib封装，有的用纯流），导致传输时解压失败。但你的场景是仅服务器内部存储啊！只要你自己统一压缩和解压的实现（比如固定用zlib的纯Deflate模式），完全不会有兼容性问题——毕竟只有你自己的代码在读写这些数据，没有第三方设备掺和。

总结一下 #

• 追求极致省空间：选DeflateRaw，零额外头部开销，压缩效率和Gzip/标准Deflate一致（毕竟Gzip本质就是Deflate加了头部尾部）。
• 怕麻烦想快速实现：用标准Deflate（带zlib极简封装），这点额外开销完全可以忽略。
• 绝对别用带头部的Gzip，纯纯浪费存储。

内容的提问来源于stack exchange，提问作者Slbox