压缩基础
压缩算法的目标是用更少的字节表达同样的信息。工程上通常需要在压缩率、压缩速度、解压速度、内存占用、实现复杂度和格式兼容性之间取舍。
无损压缩的基本闭环
无损压缩必须满足：
text
decompress(compress(input)) == input因此示例程序都应该包含三个动作：压缩、解压、校验。
常见构件
| 构件 | 作用 | 代表算法 |
|---|---|---|
| 字典匹配 | 查找重复片段，用距离和长度引用历史内容 | zlib、LZ4、ZSTD、LZMA |
| 熵编码 | 给高频符号更短的编码 | zlib、ZSTD、Brotli |
| 上下文建模 | 根据上下文预测符号概率 | LZMA、Brotli |
| 块排序 | 重排数据让相似上下文聚集 | BSC |
| 校验 | 发现传输或存储错误 | zlib、ZSTD |
评价压缩算法时不要只看压缩率
很多初学者会把“压得更小”当作唯一目标，但工程里通常要同时看下面几个维度：
| 维度 | 真正关心的问题 |
|---|---|
| 压缩率 | 节省了多少带宽、磁盘和 CDN 流量 |
| 压缩速度 | 写入链路、离线任务或实时服务能否承受 |
| 解压速度 | 读取路径、启动路径、请求路径是否会被拖慢 |
| 内存占用 | 是否适合容器、边缘设备或多并发任务 |
| 流式能力 | 能否边读边压 / 边解压，而不是整块载入 |
| 格式兼容性 | 是否容易和现有工具、协议、生态集成 |
数据特征会决定结果
同一算法在不同数据上可能表现完全不同：
- 重复片段多、结构相似的数据，通常更适合字典匹配类算法。
- 自然语言文本和 Web 资源，更容易从静态字典或上下文建模获益。
- 已经压缩过、接近随机的数据，往往压不动，甚至会因格式头和元数据变大。
- 小文件很多时，容器格式、块大小、字典训练方式经常比“算法名字”本身更关键。
实际使用时常见的三个误区
误区 1：把 benchmark 排名当成绝对结论
压缩测试高度依赖数据集、压缩级别、CPU、线程数和 I/O 环境。离开测试条件谈“某算法更强”通常没有意义。
误区 2：把压缩速度和解压速度混为一谈
很多系统真正的热路径是“读”，不是“写”。例如镜像拉取、服务启动、HTTP 响应、日志回放，经常更在意解压开销。
误区 3：忽略部署和维护成本
理论上更高压缩率并不总是更划算。如果引入新库会增加编译复杂度、部署体积、跨平台适配成本，整体收益可能反而下降。
学习建议
- 先理解重复数据如何被引用。
- 再理解概率模型如何让常见符号更短。
- 最后比较不同算法在速度、压缩率和内存上的取舍。