LZ4比gzip快但压缩率低，因其默认采用快速路径牺牲字典深度和匹配长度以提升吞吐量；zstd级别超12内存指数增长；pandas需装zstandard且pyarrow≥0.17才支持zstd；解压需按magic byte识别格式。
lz4.compress() 为什么比 gzip 快但压缩率低？
因为 lz4 默认用的是 LZ4_HC 模式里的快速路径（LZ4_compress_fast），它牺牲字典深度和匹配长度来换取单线程吞吐量，实测在 1GB 文本上能跑到 500+ MB/s，而 gzip 通常不到 100 MB/s。但它不跨块查找重复，对短重复模式（比如 JSON 字段名）效果一般。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用
lz4.frame.compress()而非lz4.block.compress()，前者带帧头、支持流式、兼容性更好 - 压缩级别设为
compression=0（默认）即可，设更高值（如 16）只微增压缩率，但速度掉 30%+ - 别直接 compress(
str)，先str.encode('utf-8')，否则会报TypeError: a bytes-like object is required
zstandard 的 zstd_compress_level 怎么选才不踩内存坑？
zstandard 的压缩级别范围是 1–22，但级别 > 12 后内存占用呈指数增长：级别 15 可能吃掉 1GB 内存，级别 19 要 3GB+。这不是 bug，是 zstd 用大滑动窗口换高压缩率的代价。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 日常用
level=3或level=6，速度接近 lz4，压缩率比 lz4 高 15–25% - 写入文件时优先用
ZstdCompressor(level=...)+compressobj()流式接口，避免一次性 load 全量数据到内存 - 如果用
zstd.compress(data, level=...)简单调用，确保data小于 100MB，否则可能触发 OOM
如何让 pandas.to_parquet() 自动用 zstd 压缩？
to_parquet() 默认用 snappy，但传 compression='zstd' 就能切过去——前提是环境里装了 zstandard 包且 pyarrow ≥ 0.17。否则会报 ValueError: Unsupported compression: zstd。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 检查依赖：
import zstandard; import pyarrow，再运行pyarrow.parquet.write_table(..., compression='zstd') - 不要设
compression_args={'level': 12}—— pyarrow 当前版本（12.x）不透传 zstd 参数，硬设会静默忽略 - 若需精细控制，改用
pyarrow.RecordBatchStreamWriter手动构造压缩器，传入ZstdCompressor(level=...)
解压时遇到 OSError: Unknown frame descriptor 怎么办？
这是典型的格式混用：用 lz4.frame.decompress() 去解 zstandard 压的数据，或反过来。两种格式帧头完全不同，lz4 解 zstd 会卡在 magic byte \x28\xb5\x2f\xfd 上，报这个错；zstd 解 lz4 则卡在 \x04\x22\x4d\x18。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 存数据时就在文件名或元数据里标记压缩类型，比如
data.zst/data.lz4 - 用
file -b data.bin快速识别：输出含Zstandard compressed data或LZ4 compressed data - 别依赖异常类型判断格式——
OSError和RuntimeError都可能抛出，统一用 magic byte 前 4 字节判断更稳：data[:4] == b'\x28\xb5\x2f\xfd'是 zstd，data[:4] == b'\x04\x22\x4d\x18'是 lz4 frame
ZstdCompressor()，会悄悄积累大量未释放的 C 堆内存。用完记得 del 或用 with 语句包住。 
