google/brotli

如果你在意的是压缩率本身而不是尝鲜，brotli 值得认真考虑；它已经是一个稳定的格式，而不是实验品。

解决什么问题

你有一批文本为主的静态资源、HTTP 响应或归档数据，要经过网络传输或者长期存储，而 deflate 压完后总觉得体积还能再小一点。此时通常的取舍是：要么引入一个不熟悉的编解码器，还得自己分发解码器；要么继续用熟悉但更臃肿的基线。换成 Brotli 只会改动编码/解码这一层：用 Brotli 编码器压缩，在已有 Brotli 解码器的地方解压，同一类数据就能得到更密的输出。文件格式和传输协议都不用动。

有什么不同

它的机制是把现代 LZ77 变体、Huffman 编码和二阶上下文建模组合起来，格式由 RFC 7932 标准化。作者称其压缩率可与当前最好的通用压缩方法相比，速度与 deflate 相近；但这是我引述项目自己的说法，不是这里复现的实测数字。最有影响的取舍是：Brotli 是流式格式，不含校验和，也不保存解压后的长度，README 明确提醒直接修改压缩流中的裸数据区间，解码器不会察觉。也就是说，完整性校验不能交给编解码器；如果你在意数据被篡改或截断，需要在上一层配合校验和或认证容器。换来的是更精简的流，而且它有多套独立实现，包括 Mark Adler 仅依据格式规范写的解码器，以及 JavaScript 和 Haxe 移植；这降低了被某一家编解码器锁死的风险。格式的普及度也够高：Debian 系发行版可用 apt install brotli 安装，macOS 用 Homebrew。

谁值得试

适合：自己控制连接两端的开发者，给静态网页资源或 API 文本开启 Brotli，压缩可压缩的响应体。也适合：想给命令行或库的流水线加一个规范清晰的小型编解码器，并且愿意在别处处理完整性校验的人，C 库加 Python 绑定已经够用。不适合：期望压缩文件能自校验、自带原始长度的人，因为格式有意不提供这两项。也不那么适合需要一份全平台自包含二进制的人：虽然 README 提到 Dart 生态有第三方预编译二进制，核心项目文档主要讲从源码构建，并没有提供统一发行版。

使用条件与边界

关键限制来自流式设计：没有校验和、没有长度字段，意味着损坏或被截断的数据也可能被解码而不会报出明显错误，校验需要放在你自己的层里。从源码构建需要 C 工具链，README 给出了 CMake、Bazel 和 vcpkg 三条路径；Python 模块可以直接 pip install brotli，所以多数人通过包管理器就能免去手工构建。README 没有说明 C 库在演示的构建系统之外覆盖哪些平台，落地前请先确认你的目标环境。日常维护主要是跟进系统包里的 brotli 版本和格式规范；由于格式已标准化且解码器有多套独立实现，风险相对分散，但现有材料没有描述版本升级或迁移策略。

HotRepo 点评

按 HotRepo 的每日榜单记录，2026-10-24 该项目有 14,997 星、当天 +16，2026-10-25 为 15,000 星、当天 +21。这里只有两个记录日期、没有更早历史，无法判断关注度能否持续；仓库创建于 2014-10-09，但建仓时间不能说明维护质量。上手前值得核实一件具体的事：你所用发行版里的 brotli 包版本，与你准备集成的解码器实现，是否对应同一个格式版本；README 指向规范本身，并没有提供兼容性对照表。