这条在讲 misa77，基于 LZ77，给“写一次、读很多次”的场景设计。出处是仓库 README。作者把基准测试直接贴文档里了，这在压缩库项目里算少见——大多数都是扔个 bench 脚本让你自己跑。
我一开始是当“又一个说比 LZ4 快的库”扫过去的。读到 Silesia 那部分才确认这条值得认真看：misa77 级别 1 在 Silesia 全部 12 个文件上解压都快过 LZ4。不是平均值，是逐个文件。
顺手跑了一下。没跑全套 Silesia，太费时间——只拿手头几个日志文件按它的示例命令跑了一遍，级别 1 解压速度确实快得明显。我机器不是 M3，跑不出文档里那个数，但 Intel 平台上的数据对得上：解压吞吐量 3846 MB/s，LZ4 1.10.0 是 2514 MB/s。压缩比这边，misa77 级别 1 是 46.74，LZ4 是 47.59。
压缩比差 0.85 个百分点，解压速度快 53%。
这个对比太清楚。读多写少——日志、发布包、只读数据集——压缩少出的那不到一个点，换解压速度快一半以上，完全不亏。不知道这些场景里为什么还有一堆人抱着 LZ4 不放。可能就因为熟悉、可靠、哪儿都有。但 misa77 这个数据摆出来，至少值得试一下。
说回 safe 模式。README 写了 unsafe 和 safe 两种解压模式，safe 保证对损坏或恶意输入安全退出。代价作者写了「约 5%」，可下面分平台的数是 x86-64 上约 3%，Apple M3 上只有 1-2%。直接写 1-3% 不好看吗。后来想想，读多写少的场景里，解压器面对的可能就是不可信来源、或者磁盘上躺了几年可能有损坏的数据，safe 模式算是刚需，保守点写是让选 unsafe 的人多留个心眼。这是我猜的，不一定对。
但有个坑得说清楚：级别 4 目前没有对应的 safe 解压器。你要最高压缩比那档，就只能 unsafe。级别 4 的编码器内存 176MB，级别 3 才 29MB——这个跳变很大。如果级别 4 换来的压缩比提升只有一两个点，还得放弃 safe 模式，那我觉得不值。不过我没找着级别 4 和 3 的压缩比单独对比的数据，这条先挂着，等我回头拿几个文件测一下再补。
内存这块提一嘴。压缩时内存固定不变，跟输入大小无关；解压时不需要额外内存。我跑大文件试了，解压时进程内存确实不怎么动。级别 -1 和 0 的编码器只要 1MB，级别 1 和 2 是 3MB，级别 3 跳到 29MB。对一次性压缩的场景来说，这些都不算事。
还有个数字我有点上头：Apple M3 上 misa77 级别 1 解压吞吐量 12638 MB/s，LZ4 是 5195 MB/s。两倍半还多。我甚至怀疑是不是 M3 的内存带宽正好对上了它的解码循环，或者 LZ4 在 ARM 上没调好。但这个数是作者自己贴的，我暂时没有 M3 机器去复现，先记下来。
已集成到 lzbench 和 TurboBench 这个事——对我这种懒人友好，不用自己写 bench 脚本。MIT 许可证，165 颗星、7 个 fork。仓库规模还小，但东西对得上号。
不点链接也能带走的一句：读多写少的场景里，压缩比差一个点可以忽略，解压速度快一半是实打实的；safe 模式真实代价大概 1-3%，别被「约 5%」吓退——但别用级别 4，那档没有 safe 解压器。