facebook/zstd：面向实时场景的高速无损压缩与解压工具
一个给实时数据做无损压缩的 C 库和命令行工具，速度快，还能用 dictionary 优化小记录。
GitHub facebook/zstd 更新 2026-09-09 分支 dev 星标 27.8K 分叉 2.6K
C/C++ 无损压缩 libzstd Linux/Unix

🧭 决策指南

为什么现在热： 无法从材料判断

适合，如果你

  • 你需要在 Linux 数据流中以 zstd CLI 或 libzstd 做实时无损压缩
    README 开头将 zstd 描述为 targeting real-time compression scenarios，并提供 C library 与 command line utility
  • 你的服务处理约1KB、同类型且相互关联的小记录
    README 的 The case for Small Data compression 章节以约10K条、每条约1KB的 github-users 样本说明 training mode 和 dictionary
  • 你的 C/C++ 工程希望用 make、CMake 或 Buck 构建 libzstd
    README 的 Build instructions 章节分别给出 make、cmake 和 buck 构建方式

不适合，如果你

  • 你希望所有数据类型共用一个 dictionary，而不维护按类型划分的 dictionary
    README 明确写着 there is no universal dictionary，并指出每种数据类型使用一个 dictionary 效果最好
  • 你的首要目标是基准中的最高解压吞吐，而不是 zstd 的压缩比与速度折中
    README Benchmarks 中 lz4 1.10.0 解压为3850 MB/s，高于 zstd 1.5.7 --fast=4 的2050 MB/s

前置条件

  • 系统需支持 standard make 或 gmake；README 称 make 是项目的 main build system。
  • 使用 CMake 时可执行 `cmake -S . -B build-cmake` 和 `cmake --build build-cmake`。
  • 运行 `src/tests/playTest.sh` 时，需要 `$ZSTD_BIN` 和 `$DATAGEN_BIN` 指向 zstd 与 datagen binary。
  • 使用 dictionary 时，README 要求先用样本训练，并在压缩和解压前加载该 dictionary。

第一步命令（README 原文）

make check

要注意

  • 负压缩级别 --fast=# 会提高速度，但 README 明确说明会牺牲压缩比。
    README 的 Benchmarks 章节：The negative compression levels ... offer faster compression and decompression speed at the cost of compression ratio
  • dictionary 的收益主要集中在前几个 KB，后续内容会依赖已解码内容继续压缩。
    README 的 Dictionary compression How To 及其说明
  • CMake 默认将 CMAKE_BUILD_TYPE 设为 Release，不能直接视为 Debug 构建。
    README 的 cmake 章节明确写着 By default, CMAKE_BUILD_TYPE is set to Release

替代方案

  • lz4：当解压吞吐优先时，README 基准中 lz4 1.10.0 达到3850 MB/s，高于 zstd 1.5.7 --fast=4 的2050 MB/s。
    README：Benchmarks
  • brotli：当基准中的压缩比略高于 zstd 1.5.7 -1 时，brotli 1.1.0 -1 的比值为2.883，而 zstd 为2.896；该差异需结合速度数据理解。
    README：Benchmarks
  • zlib：当现有系统明确依赖 zlib 1.3.1 或其兼容生态时，可优先考虑 zlib；README 将其列为对比算法。
    README：Benchmarks

材料未说明

  • README 未给出 Windows Visual Studio、Meson、VCPKG、Conan 和 Bazel 的具体构建步骤；相关章节在材料中被省略。
  • 材料未说明 zstd 1.5.7 相对旧版本的兼容性变化、升级迁移要求和 ABI 细节。
  • GitHub 元数据将许可协议标为 Other，而 README 写明是 BSD OR GPLv2；材料未解释两者的展示差异。
  • 材料未提供目标硬件、实际输入数据和业务吞吐下的 benchmark 结果。
  • 材料未列出具体编程语言 bindings，也未确认某个目标语言是否已有可用 port。

💡 深度解析

6
不适合 我的 Linux 分发服务当前使用 lz4，硬件接近 README 的 Core i7-9700K，并且最重要指标是最高解压吞吐；即使能减少存储和带宽，我是否应该改用 zstd？
适合读者： 维护使用 lz4 的 Linux 分发服务、在 Core i7-9700K 基准级硬件上极度优先解压吞吐的基础设施工程师

不适合直接替换，因为 README 基准显示 lz4 的解压吞吐明显高于 zstd；只有压缩率或跨场景可调性足以抵消吞吐损失时才应重新考虑。

  • 在同一套 Core i7-9700K、Ubuntu 24.04、GCC 14.2.0 和 Silesia 基准中，lz4 解压为 3850 MB/s，zstd -1 为 1550 MB/s，zstd –fast=4 为 2050 MB/s。
  • zstd 的优势是压缩率和可调速度：zstd -1 比 lz4 的 2.101 达到 2.896，但这不改变 lz4 的解压优势。
  • README 还说明 zstd 的 --fast=# 会牺牲压缩率换取更快速度；即使使用 fast=4，解压仍低于该基准中的 lz4。
  • 因此，如果你的约束明确是“最高解压吞吐”，项目数据不支持迁移结论；若瓶颈转为网络或存储容量，才有进一步比较价值。
  • Benchmarks：lz4 1.10.0，Ratio 2.101，Compression 675 MB/s，Decompress 3850 MB/s
  • Benchmarks：zstd 1.5.7 -1，Ratio 2.896，Compression 510 MB/s，Decompress 1550 MB/s
  • Benchmarks：zstd 1.5.7 --fast=4，Ratio 2.146，Compression 665 MB/s，Decompress 2050 MB/s
  • 原句：The negative compression levels ... offer faster compression and decompression speed at the cost of compression ratio.
材料未说明：README 未说明你的分发服务中网络、磁盘和 CPU 哪一个是实际瓶颈。；README 基准不包含你的文件类型、并发度和端到端缓存行为。
适合 我现在的 Linux 服务使用 zlib -1，服务器接近 README 基准中的 Core i7-9700K；如果我要降低压缩耗时并提高压缩率，同时保留很快的解压速度，zstd 是否适合替换？
适合读者： 维护基于 zlib 的 Linux 服务、使用 Core i7-9700K 级别服务器、同时受压缩延迟和网络带宽约束的后端工程师

适合，因为 README 的同一组基准显示 zstd -1 在压缩速度、解压速度和压缩率上都高于 zlib -1。

  • zstd -1 的压缩率为 2.896，压缩速度 510 MB/s，解压速度 1550 MB/s；zlib -1 分别为 2.743、105 MB/s 和 390 MB/s。
  • 项目定位是“fast lossless compression algorithm”，目标包含实时压缩场景，并支持按小步调整速度与压缩率。
  • 如果在线路径更看重延迟，还提供 --fast=# 的负压缩级别；README 明确说明它以压缩率换取更快的压缩和解压。
  • 格式由 RFC8878 文档化，且已有多个独立实现，适合规划替换后的长期数据交换。

不过，README 基准只覆盖特定 CPU、Ubuntu、GCC 和 Silesia 数据集，不能直接代表你的服务端到端收益。

  • Benchmarks：zstd 1.5.7 -1：Ratio 2.896，Compression 510 MB/s，Decompress 1550 MB/s
  • Benchmarks：zlib 1.3.1 -1：Ratio 2.743，Compression 105 MB/s，Decompress 390 MB/s
  • 原句：Speed vs Compression trade-off is configurable by small increments.
  • 原句：The negative compression levels, specified with `--fast=#`, offer faster compression and decompression speed at the cost of compression ratio.
  • 原句：Zstandard's format is stable and documented in RFC8878.
make
材料未说明：README 未给出你的实际数据集、CPU、I/O 和服务端到端延迟结果。；README 未说明从现有 zlib 数据格式迁移时的兼容策略和回滚方案。
视情况 我维护的是 README 示例中约 10K 条、每条约 1KB 的 GitHub API 用户记录；如果单条对象太小、普通压缩收益有限，我是否应该使用 zstd 字典？
适合读者： 维护 10K 个约 1KB GitHub API 用户记录、需要降低 API 响应体积的服务端工程师

视情况，只有这些 1KB 记录在结构或内容上具有稳定相关性时，zstd 字典才值得采用。

  • README 说明数据越小越难压缩，因为新数据集开始时没有足够历史上下文；这正是字典机制针对的问题。
  • 示例使用约 10K 条、每条约 1KB 的 GitHub 用户记录，通过若干样本训练 dictionary，并称小数据压缩率可显著提升，同时压缩和解压速度也能提高。
  • 字典必须在压缩和解压前加载，而且 README 明确说“there is no universal dictionary”；按数据类型使用专用字典更有效。
  • 如果记录之间缺少相关性，或者字典分发、更新成本高，收益可能不足以抵消集成复杂度。

因此，决定点不是记录数量本身，而是样本是否代表线上数据，以及两端能否一致管理字典。

  • The case for Small Data compression：示例为 roughly 10K records weighing about 1KB each
  • 原句：The smaller the amount of data to compress, the more difficult it is to compress.
  • 原句：Using this dictionary, the compression ratio achievable on small data improves dramatically.
  • 原句：The result of this training is stored in a file called "dictionary", which must be loaded before compression and decompression.
  • 原句：there is no universal dictionary
材料未说明：README 未提供你的线上记录与示例样本之间的相关性指标。；README 未说明字典大小、更新频率、分发协议和旧字典兼容策略。
适合 我需要把压缩能力嵌入 C/C++ 数据库或消息系统，并用 CMake 产出同时支持 Apple Silicon M1/M2 与 Intel 的 Universal2 构建；zstd 是否符合这个集成约束？
适合读者： 在 C/C++ 数据库或消息系统中嵌入压缩库、同时使用 CMake 和 Apple Universal2 构建的系统软件工程师

适合，因为项目提供可嵌入的 C 参考库、CMake 构建路径，并在 README 中直接给出 Universal2 的构建与安装命令。

  • README 将仓库定义为开源双许可证 C library，同时提供命令行工具；这比只提供 CLI 更适合数据库或消息系统直接集成。
  • 项目支持流式压缩、解压和大文件处理，适合嵌入需要增量处理的系统，但具体 API 生命周期仍需按库文档实现。
  • README 说 make 是参考构建系统，同时列出 CMake、Meson、Buck、Bazel、VCPKG、Conan 和 Visual Studio 等路径；CMake 可满足你的构建体系。
  • Universal2 章节明确包含 x86_64、x86_64h 和 arm64 架构，并给出 Ninja 构建安装流程。

许可证不是简单的单一 BSD 条款，而是 BSD 或 GPLv2 双许可证；企业分发方式仍需完成内部审查。

  • README 开头：open-source dual BSD OR GPLv2 licensed C library
  • 原句：Zstandard supports streaming compression, decompression and large files
  • Build instructions：`make` is the main build system of this project
  • Support for Fat (Universal2) Output：Apple Silicon (M1/M2) as well as Intel
  • README 命令：cmake -S . -B build-cmake-debug -G Ninja -DCMAKE_OSX_ARCHITECTURES="x86_64;x86_64h;arm64"
cmake -S . -B build-cmake-debug -G Ninja -DCMAKE_OSX_ARCHITECTURES="x86_64;x86_64h;arm64"
材料未说明：README 未给出你所需 C/C++ API 的具体版本兼容承诺和 ABI 管理策略。；README 未说明你的构建系统与 CMake 之间的具体选项差异。；README 仅说明双许可证形式，未替你的分发模式做法律判断。
适合 我需要在 Linux 上批量处理 .zst、.gz、.xz 和 .lz4 文件，并希望用一个命令行工具完成压缩与解码；zstd CLI 是否适合，而不是只把它当作库？
适合读者： 负责批量处理 .zst、.gz、.xz 和 .lz4 文件的 Linux 运维工程师，希望用一套 CLI 替代多套格式工具

适合，因为 README 明确说明 zstd 仓库同时提供命令行工具，并能生成和解码 .zst、.gz、.xz 与 .lz4 文件。

  • 这满足你需要统一 CLI 处理多种既有格式的约束，而不只是提供 C 库 API。
  • README 的 Build instructions 说明 make 是项目的主要构建系统，命令行工具可从源码构建；基础压缩、解压和安装路径的学习成本较低。
  • 项目还支持可调压缩级别和 --fast=#，因此批处理任务可以在速度与压缩率之间选择不同档位。
  • 但“能处理相关格式”不等于所有格式的行为完全等价；README 未列出你批处理脚本所需的全部参数、元数据保留规则和错误码语义。

如果你的目标是统一入口和常见格式转换，适配度高；如果依赖某个格式的高级特性，现有 README 证据不足以直接确认。

  • README 开头：a command line utility producing and decoding `.zst`, `.gz`, `.xz` and `.lz4` files
  • Build instructions：`make` is the main build system of this project
  • 原句：Speed vs Compression trade-off is configurable by small increments.
  • 原句：The negative compression levels, specified with `--fast=#`...
make
材料未说明：README 未列出各格式转换时的完整 CLI 参数和元数据保留行为。；README 未说明批处理脚本可依赖的全部退出码和错误输出格式。
视情况 我维护一个跨语言消息协议，发送端准备使用 zstd 的 C 库，接收端不是 C/C++；如果我需要稳定格式和独立实现之间的互操作，zstd 是否适合作为协议压缩层？
适合读者： 维护跨语言消息协议、希望让 C 参考实现与其他语言实现互通的分布式系统工程师

视情况，格式互操作的基础条件较好，但你的接收端语言是否有成熟、兼容的实现，README 并未替你确认。

  • README 说明 zstd 格式稳定并由 RFC8878 文档化，且已有多个独立实现，这对跨语言消息协议是明确的正面信号。
  • 仓库本身提供的是 C 参考库；README 将其他语言支持放在 Zstandard homepage 的 ports and bindings 列表中，而不是承诺仓库内置完整语言绑定。
  • 如果消息采用流式传输，项目支持 streaming compression 和 decompression，但接收端仍需正确处理帧边界、部分输入和错误情况；README 选段没有给出协议封装规则。
  • 双许可证为 BSD 或 GPLv2，格式层可用性与企业分发许可是两个不同决策，不能只因格式开放就跳过许可审查。

因此，格式层面值得考虑；语言绑定质量、版本同步和协议错误语义仍是决定性未知项。

  • 原句：Zstandard's format is stable and documented in RFC8878.
  • 原句：Multiple independent implementations are already available.
  • README 开头：a reference implementation ... C library
  • 原句：a list of known ports and bindings is provided on Zstandard homepage
  • 原句：open-source dual BSD OR GPLv2 licensed C library
材料未说明：README 未指出你的目标语言对应绑定的维护状态、版本同步情况和错误处理方式。；README 未定义你的消息协议如何封装 zstd 帧、处理截断输入和协商字典。；README 未对你的企业分发模式给出许可证结论。

✨ 核心亮点

  • zstd 1.5.7 -1 压缩510 MB/s、解压1550 MB/s
  • 格式遵循 RFC8878，并提供 C 库与 zstd CLI
  • 训练模式用 dictionary 改善约1KB小数据压缩比
  • make、CMake 和 Buck 均可构建 libzstd 与 zstd

🔧 工程化

  • zstd CLI 可生成并解码 .zst、.gz、.xz 和 .lz4 文件
  • libzstd 支持实时压缩，并以小步长调节速度与压缩比
  • zstd --train 生成 dictionary，供小数据压缩和解压共同使用

⚠️ 风险

  • README 基准依赖 Core i7-9700K、Ubuntu 24.04 和 Silesia 数据集
  • dictionary 必须先训练，并在压缩和解压时同时加载
  • README 明确指出不存在适用于所有数据类型的 universal dictionary

👥 适合谁？

  • 需要 C 库或 zstd CLI 处理实时文件和数据流的 Linux 团队
  • 处理大量小记录并能维护按数据类型划分 dictionary 的服务
  • 需要 make、CMake 或 Buck 集成 libzstd 的 C/C++ 工程